![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
The very first step is broken here: you fork the repository. At this very moment you are off the main community and noone knows what's going on. You hack but hack alone. Currently one can review the 'entity system' issues in one central place where discussion and code is happening (github separates issues from pull requests). This coherent, single, participatory, inclusive system is missing. We do not want people going off and working separately, making their work visible only when they think it's ready. Not to mention that github doesn't have priorities, components and anything besides tags.
Commenting on this Story is closed.
Because “patch” sounds like a shit from a geek world.
Having worked extensively with both workflows, I'd have to disagree. Forks are not hidden, nor private, nor exclusive. And they must be kept current with the repo or be rebased... or both ideally. The PRs themselves are branches while the forks should be identical. So not the traditional use for the word "fork." The branches can be worked on by multiple people. We have many people sometimes working on a branch in a fork that ends up being a single PR. Imagine if you had multiple people working on a patch? How do you accomplish that? Also, this workflow is pretty common when it comes to Drupal 8. Twig, for example, was made in a completely separate fork. Twig implementation would've been much simpler with a PR workflow. For me, the advantages of Git/PR based workflow far outweigh the patching workflow used by Drupal. Yes PRs are separate from issues but are cross referenced and easy to follow. A PR workflow is not exclusive to GitHub and Drupal could adopt one that worked similar to the current patch workflow if there was a will for it. Right now, I think the patching workflow will live on because people are used to it. And that's fine... I guess, but I don't think it's fair to call a different workflow "inferior", especially when your basis for that is mostly a difference of opinion.
Inferior for who? For someone who is already used to the current workflow and can roll patches with their eyes closed, yeah, this post makes sense. But for someone who has never tried it then the barrier to entry is much lower with GitHub's workflow (i.e., click fork, make edits, click pull request, write comments--all in the GUI if you like).
Is a lower barrier to entry a good thing? I suppose that's another conversation entirely. But either way, your post focuses on things that are good for the heavy Drupal contributors and ignores those who haven't tried it and likely won't if they have to learn a whole new workflow for it.
I think that, whenever possible, the lower barrier to entry is ABSOLUTELY a good thing, particularly in an OSS project like Drupal.
It has its pros and cons. More random one-off pull requests from devs means that we get some cool contributions that we wouldn't have otherwise gotten, but it also means that we get a lot more junk that maintainers have to wade through. That is, I predict that it would lower the average quality level of contributions while increasing the quantity.
I think i have to disagree on that last bit.
True, we will have more stuff to review, but the review-bit also could use some UI tools, speeding up the review/test process and also opening this up to less experienced people, and thus, possibly (for sure) speed up growth of knowledge. And that's even more important then having an increase of like 25-50% on code contributions.
We'r not only developing, we'r also educating people, please do not forget this. We can do this just fine with high standards (PLEASE!), a project/patch should only be released/accepted if the quality is ok, and we already have a couple 'of those' projects that are kinda buggy. But if the projects are really important / interesting, they get the support they deserve anyway eventually. (even if they are really really broken) And that group that offers this kind of support can only explode in size if we make it more accessible to a larger group of people.
Yeah i used 'explode', because we still got a lot of developers who never even tried Drupal, so i would like to chip in the idea to not forget that huge group.
There is absolutely no reason I can't be a Perfectionist Pat or a Sloppy Sam with GitHub or d.o. There is no difference. Also, while you can't convert issues into PR's anymore (sad), you can link a PR and an issue so that when the PR is merged, the issue is closed.
The point about tags is valid. Obviously, you could still use tags for priorities, components, and more specific statuses, maybe with a bot to make setting these easier (only committers can).