Recent comments

I agree.

And this is the chance for us:
When we change the forums and support on d.o so, that it will be more usable -> then by this work we will achieve BETTER contribs at the same time, and they would be after that used by all the drupal poeple!
It will increase both the universality and the utility of the Drupal, when there will be better contribs for easy making modern support/forums as the part of the Drupal sites.

SE does not work for everybody but it works for most.

You may have been frustrated asking or answering a question on SE but I will bet you the next beer that you have discovered more excellent answers or questions on SE than on drupal.org.

I am often surprised when great questions that need more debate (IMHO) are closed down by 'rock-star' members who are SE reputation millionaires.

But these same people are the ones who are most willing to answer or improve a question and they put much effort into this because their reputation is at risk.

If you ask a stupid question (one that has been answered) or provide a stupid answer (sometimes called an uninformed opinion) then you can expect to be challenged and collect some down votes.

SE is a amazing free market model for harnessing the wisdom of the crowd.

Drupal.org should learn from this. It is time to stop behaving like Microsoft or Blackberry. The world is changing. Realize that you may no longer be the Smartest Guys in the Room.

http://en.wikipedia.org/wiki/The_Smartest_Guys_in_the_Room

The last time I looked, there was not one link on drupal.org to Drupal Answers. This is so wrong.

This gets gnarly because then patch reviewers then have to learn two ways of getting their patches downloaded and onto their computers for testing. Since patch reviewers are both our most precious and our scarcest resource, I'm not eager to throw barriers in front of them.

We definitely have hit the outer limits of the current testing architecture, so +12837923 for this general idea. I also like that it leaves the question of dog-fooding it or not off the table, so we can discuss this idea on its own merits .

I have a number of questions about this...

1) How much (if any) of Jimmy's work on the D7 version of testing tools would be applicable here?

2) How close would something "off the shelf" like Travis CI get us there? I'm seeing a lot of support generally in the highest-rated proposals of letting other people solve these types of problems for us, and we handle the integration (PIFT or PIFR, I can never keep those two straight :P).

3) I get that this is "High difficulty," but I guess I'm wondering if this is a 24 month project or a 2 month project (assuming the DA dedicated staff time to help with implementation, which it may or may not be able to). It might be that it's literally impossible to say, but even a ballpark would help us figure out where in the roadmap something like this could go.

Nice, simple improvement that would help prevent project duplication, and less ambitious than https://groups.drupal.org/node/312893 (which would still be cool).

Github is awesome.

Maintaining our own git infra is way too much work and we're making way too little progress. People who say we shouldn't offload this but who haven't been involved in making this work should step back a step.

Yes, GH's issue queue is inadequate, and we'd have to figure something out. The issue queue is also the thing that would be most at risk if we moved to GH and it somehow changed. So there's another good reason to figure out how to control it ourselves.

I don't imaging this being too complicated on the review process. Just add a plus to comments in the issue queue that would give review points. Just make it so you can plus your own comments. Simple Ajax on the plus sign to so you don't even need to leave your page. 1 Plus per issue.

Why not allow both, if people want to upload a patch, they can do it. If people want to fork and create a PR they can as well.

I think both patches and PR have their merits, so we should aim to make it contributors as easy as possible.

@Crell

PRs, in their current form, tend to favor a single "champion" for an issue with 0 or more people backing him up via nested PRs. That works well when one person is really driving an issue, which is often but not always.

Two different ways around this:

1. Nothing is stopping me from forking your PR and submitting a new PR off of my own repository. The issue-to-pull request relationship is one-to-many, since there could be different ways to solve the same problem. Which is the "better" solution is up to the project maintainer and for the two contributors. The issue-to-patch relationship is one-to-one, meaning one problem has one solution. We've had troubles with that past, but that's another argument.
2. Another thing I could do is fork your fork, and submit a PR to your fork. This allows me to submit improvements to your solution. Whether you bring those changes in is up to you. Otherwise, see #1

Again, it's all about communication, and working together. We run into problems with patches, and we run into problems with pull requests. Different workflows, it all just comes down to working together to make the world a better place.