Recent comments

Thanks, I did search :)
Updated OP to link to other issue, added screenshots over there.

see https://groups.drupal.org/node/313158

To add to this there is also a CI component: https://github.com/gitlabhq/gitlab-ci

It has the concept of multiple runners and integrates right into gitlab (built by the same group).

It's a shame this proposal didn't get more love from the community; those most voted for seem very dev oriented xD. Personally I don't think bluecheese is a good representation of what Drupal is capable of theme wise. We did an unsolicited design based around what we thought was the most important part, the community.

https://dl.dropboxusercontent.com/u/34274659/Freelance/Drupal/drupal.jpg

Sadly it seems this won't be up for discussion again until after the next release? Hopefully we can get some more push then.

I'm with you about the concerns you have, they maps well with my own.

As has been said elsewhere, our issue queue is fairly unique

The uniqueness of our issue queue is our own creation really. An issue queue is nothing complex, its actually very straightforward in the way it works.

Over the years we have tweaked it, we have taken many shortcuts in the implementations. Shortcuts instead of looking at the bigger picture of how an issue queue should work. The result is an IQ that quite frankly only is usable on d.o and for the development needs.

We use the issue queue for many non developing things too, but those queues are often hard to find, make any sense of and finally use.

We can change this though. We just need to change out attitude from looking at it as something that is not working for us to something that once again can help us push forward and drive development.

I had come across these taxonomy term pages before, but they are showing incorrect results sometimes. For example, under the "Seeking new maintainer" term, on page 3, there are projects with "Minimally maintained", or even "Actively maintained" status listed!
Maybe we should file a bug somewhere?

I really do think this could be a greener on the other side situation.

As has been said elsewhere, our issue queue is fairly unique, so maybe what supposedly works for everyone else isn't a good fit for us.

What caught my eye here was "I would expect massive community disruption" and I'm not sure if even massive is strong enough a word.

This is changing our whole development workflow, which can be hard with a team of 4 let alone a team of thousands.

I know change is not something to be scared of but it is a huge and risky change.

Having to sign up for a new account because it is external to drupal.org and then learn a new tool is big.
I think because this is a developer focused discussion it might be underestimated how many people on drupal.org do not have github accounts and might be put out by the extra hurdles.

"Familiarity to new contributors who are used to github" has been mentioned, however that goes both ways. What about people who don't use github? They exist.

If issue queues go as well there are very large problems regarding people not being able to modify details of an issue, or move an issue to a different queue, or upload files, etc.

Maybe we can cross our fingers and hope github will change the way things work for us but it is not good to rely on external factors out of our control and it is very likely that not all of our requirements, if any, will be things they want in github.

I don't think it would be a matter of us off loading all our custom version control code to an external service, we're still going to have custom code somewhere if we are keeping ANY parts of our own, like project pages with release tarballs, issue queues, etc. and we would also probably be creating new custom code to integrate github to the parts of ours that we are keeping.

It seems that a lot of the benefits of github are helpful addon features, which should be implementable in our current system, possibly even with equal or less work overall.

Seems like it might be easier to implement what we are lacking on our end than to get github to implement what they are lacking (pure speculation as github is an unknown in regards to getting features added/changed).

These are not new points but they are concerning.

Create "Need Maintainers" project to find new maintainers for projects :)

Case in point, just after posting my initial comment here, I needed to search for a rather wordy error message. Like you, my first inclination was to go to Google. I typed 'drupal 7 "my long error message here in double quotes"' -- Google got NO hits.

I then searched the same string in drupal.org and the top hit was posted yesterday. Google had not had time to index that page yet. Granted, that won't be the case most of the time, but when an issue is introduced by a newly released version of drupal or contributed modules, many of the posts (and the inevitable searches) will be within hours or a day or two - way before search engines can do their thing. When I do a search, I certainly want to know I'm seeing ALL possible matches.

I realize how complicated the coding could be to create the ultimate search feature for drupal.org, but it wouldn't be that much work to simply force a version selection when creating a thread and offering a filter based on that. In addition to the obvious version choices, it could also have "Pertains to all versions" and "Not version-specific".

That would significantly reduce the level of frustrations I think many visitors experience when searching the forums.