Welcome
Welcome to the brainstorming group for the 2014 Drupal.org roadmap! This group is to help the Drupal.org Software Working Group gather community input into the 2014 budget and plans for Drupal.org improvements. Please read the announcement for more background/details.
Latest ideas Most popular Recent Comments
To participate:
- Review the list of submitted proposals and "vote up" and/or comment on ones that speak to you.
- If you don't see your idea reflected, propose your own ideas using the idea template.
- While we want to hear about everything that's on your mind, we're especially interested in small, but impactful ideas.
- Proposals are wiki pages, so feel free to provide additional details in other peoples' proposals; think of them as "issue summaries" for ideas, so keep them neutral.
Voting/feedback will considered until 00:00 GMT on September 6, 2013, in order to give us ample time to make a proposal (which the results here will be a part of) for the Drupal Association Board Retreat prior to DrupalCon Prague. Thanks for participating!
Subscribe with RSS 
Recent comments
I'm here
Hi attiks, thanks for the invitation. I'm a GitLab.com co-founder and we would love to have Drupal use GitLab. I'm wondering about one thing, would you need public repo's?
So moving to GitHub means we
So moving to GitHub means we have to use their issue queues (at least according to you and webchick). That presents a whole bunch of problems, but I think the worst one is that it takes us a major step away from eating our own dog food.
Maybe if we were just starting a new project today it would make more sense, but we have what we have now. In terms of using our own site-building system to build our site, we should be gaining more ground, not less.
Awesome, that's really
Awesome, that's really helpful feedback on where exactly the shortfalls in Github's issue tracker are! Could you somehow add this information (or a pointer to it) in the issue summary?
Disclaimer: I'm not aware of
Disclaimer: I'm not aware of all the technologies that Github's ecosystem could provide use. E.g. maybe composer could help with packaging. So, I'm posting these as a comment first. They can be moved into the summary or merged once they've been vetted/responded to.
A big reason to move to github is that "someone will maintain stuff for us" but the below list is stuff that Github either definitely or probably won't maintain for us. So we would still be responsible to maintain things that require a large amount of effort to upgrade them between upgrades of Drupal.org (e.g. D6 to D7).
Problems with the GitHub issue tracker
I have had the distinct displeasure recently of using GitHub on a group project (building a Drupal site). Although I agree that the code/pull stuff is fine, the issue tracker leaves a lot to be desired, and I think it would be a huge step backwards for us to switch from the issue tracker we currently have on drupal.org to using Github.
Here is a list of a few essential things we can do now with our issue tracker that we can't do on Github as far as I know:
a) project/issues/user (list of issues across all projects that you are following) - as far as I know this does not exist on Github.
b) BIG ONE: you cannot attach files to issues. Period. This is IMO a complete show stopper.
c) Meta-data fields such as component, severity, version, etc. You can file an issue and it's on a particular project, and you can tag it "needs review", "feature request", etc, but we have a much richer set of meta-data than what exists on Github. Fields I think we would need that are lacking:
- Branch/tag/version
- Severity
- Type (bug, feature request, etc.)
- Status (needs review, RTBC, etc.)
d) UI for listing comments lacks numbering and date/time. All it shows is "10 minutes ago" and "yesterday" etc. It makes it pretty difficult to say "In comment #3, Jane said...". You can make a permalink but who wants to click on that and jump to that spot?
Those are the big ones... Basically it's a very minimal issue tracker and I think it would be a huge mistake and a huge step backwards in functionality to switch to using it. I seriously think it would hamper my ability to contribute to the Drupal project, to use that issue tracker as I've seen it operating. Really horrible.
Wha?
Moving Git storage to GitHub but otherwise leaving the issue queues as they are on Drupal.org offers exactly zero benefit, other than people trying to use PRs on GitHub and being confused and lost when we ignore them or tell them they need to use some other site.
The PHP-FIG group does that now, and we constantly get people filing PRs or discussing on PRs instead of the mailing list, like we keep telling people to do.
IF we move to GitHub, we move the issue queues as well. There's no point otherwise. It's not like the disk space of the repos is expensive.
Test site
I installed it on my local machine, and will try to install it on a public server sometime this week, so it can be tested.
Did you checked the gitlab
Did you check the gitlab one as well? It's similar to github, but the good thing is that it can be changed.
Pull requests, done properly,
Pull requests, done properly, actually enforce letting others know about what you are developing for the module. A pull request can easily be updated by pushing commits to the branch, others get notified and we don't have to care about interdiffs.
What needs to get thought through is how multiple users contribute to a single pull request. i have linked before the lengthy discussion that already happened around that topic.
Agreed on the issues
The issue tracker on github is really really terrible and we'd be losing pretty much all of our useful issue tracker features if we went with github.
If we don't want to keep issue tracking ourselves, we need to adopt a real issue tracking system like Bugzilla. If we adopt Github's issue tracker, I think it will become nearly impossible for me to do what I do now using the Drupal issue tracking system.
Amended that part now
I agree with you there Jennifer and have changed it to a somewhat more negative one now.
But please also see the risk section in the proposal where I say that it should be possible to demote projects that fail to follow through on this scheme.
I also believe this idea will help to better promote all those project maintainers and developers that already does a great job. Some almost applying the core guides even. This would make them stand out from the crowd in the way they really deserve to stand out.
Also, I think we should not underestimate the educational opportunity with a scheme like this. It would draw on the experience gathered over 10+ years into a single document about the best practices of maintaining Drupal contrib projects. Something that most developer have to figure out on their own today.
Review Board
My partner, who works at a commercial software company developing C/Java/Perl code, uses an open-source code review tool called Review board. Every time he sees me reviewing a patch in the drupal.org issue queue he bangs his head in consternation and says we should be using Review Board. The main killer features:
- See the changes visually - you can do this now at the command line if you know what you're doing with diff, but would be nice to see automatically on line and this is about all moving to GitHub would buy us.
- Comment on particular changes and have a discussion about them. The comments are shown along with the changes. Killer!!!!
http://www.reviewboard.org/
Take a look at the screen shot... I think that is what we should adopt.
.
Of course there is nothing stopping someone from forking and adding the github features like issue queue, wiki, etc... to their own fork.
I see that as a benefit and a trade-off of Github because on the one hand it makes it easy to turn on/off features, and the other hand it doesn't necessarily solve the core sandbox project vs core issue issues from D8 development cycle.
File issues...
This seems to have quite a few unrelated api.drupal.org improvements in it... these would be better filed as issues in the API module at https://drupal.org/project/api (that is the module that generates api.drupal.org).
Github issue tracking is awful
I am using GitHub for a group project developing a Drupal site, and I personally think that their issue tracker is terrible, compared to what we have now on drupal.org. Using the Github tracker would be a big step back in issue queue usability for my purposes. I can't even begin to elaborate on all of the features we take for granted in issue tracking that it doesn't have, because it's so basic that it has hardly any features.
Disagree on the premise
Just a note... The start of this post says that D7CX was a success. I disagree: yes, many people signed up for it, but very few actually followed through by making a release of their project when D7 was out. Some of them have not yet made a release, a year or more later.
Because of this, I think that just because someone opts in to following a standard does not imply that they will follow through, so I am not sure what this proposal buys us.
It is very easy to fork and
It may be happening TODAY in d.o, silently. Discussed here: https://groups.drupal.org/node/313068#comment-953538
This is also not a problem. Releases will still be published in d.o with a link to the real repository. See: https://groups.drupal.org/node/313068#comment-953468
This is true. However, from my own experience, other developers only take a look on somebody else's sandbox when the owner is talking about it and gives a link for it. Sandboxes are NOT separated from full projects on user profiles (it should be changed). Moreover, nobody (maybe a few people) is watching other user profiles to find sandboxes that may have useful code, again it is found only when the owner gives a link to it.
Pretty much.Answers come
@webchick Pretty much.
Answers come from those who know the most about what's being asked, for Drupal, that's usually the developers. If they don't see the questions, then they can't even think about answering them. We could use the integration between the question site and the issues/project stuff to make sure the questions get seen.
'Course, all this is just my opinion...
Heck, maybe all we really need is for users to tag their forum posts with projects that might be/are applicable, then have those posts show up in a view on the maintainers dashboard.
If I understand things
If I understand things correct, moving to github will make it easier to use forks instead of patches to work on improvements, and then push back those to the main project. Is that correct?
If so, how easy will it then be for users to keep track on what is going on and participate? How will I easily find these improvements and be able to test them?
Someone who use Drupal to build sites with, find a bug or suggest an improvement need to be able to easily follow and participate too. And it needs to be on a level that doesn't require them to learn tons of new skills that is very far from their actual roles.
While not optimal, nor perfect, d.o is accomplishing this really well. A lot better than most other open source projects I have got myself into.
I guess that is possible
I guess that is possible.
I feel that regardless of what happens there will still be some questions that don't get answered, or are poorly answered.
I don't think there is any way around that.
Having the tight integration would definitely help, however I'm not sure "whatever website the developers hang out on" will ever be one single place.
Maybe I'm wrong though and the main reason that people moved to stack overflow at all was because of a lack of features on drupal.org.
A single point of support is probably going to be easier for newer users, however with google it shouldn't really matter.
Plus there are poeple who spend a lot of time in the drupal.org support areas who would not appreciate being shut down in favour of SO, and vice versa.
I don't think it is really that bad a thing to have multiple sources of information if they are all of reasonable quality, so I think making the drupal support areas better where possible would be a great thing.
The risks are valid though.
[edit]
A good example of a support forum that doesn't work because it has been separated is the drupal commerce one on drupalcommerce.org (at least in my opinion).
It has a very large ratio of unanswered questions. I think this is because it's away from drupal.org, and because it requires you to make an account on another site.
On top of this, there is still a large number of support requests in the drupal.org issue queue so the idea hasn't worked and has resulted in more fragmentation and confusion.
So while I think external places like stack exchange are ok, external support queues for individual projects are bad, so if there was a better support section on drupal.org maybe people would not want to do this. Plus I think we would win some people back from stack exchange.