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
Sure?
I think you and I would be competing for that honor ;)
No, that's why we want to
No, that's why we want to move our Git repositories to Github and integrate with the Github API in the issue queue. I'm not convinced that we want the whole enchilada :-)
And don't worry about simplytest.me: it will work regardless where the Git repositories are, it will still pull data from drupal.org to locate them.
There's much more to it
After reading through this whole thread I clearly get the impression that the proposal stems from issues with the current code production and collaboration workflow. While that is a very important part of development, there are a lot more that needs to be taken into count.
One of the aspect of the Drupal community I love the most, is that it is fairly easy for almost anyone, including with no coding skills, to start participate through the issue queue.
@webchick had good arguments, https://groups.drupal.org/node/313068#comment-953633, that moving to github isn't about picking parts we like there and keep the rest on existing features on d.o - "In other words, people who use Github use the whole enchilada"
That would mean moving the issue queue too. What features would we then lose? Take moving issues between projects as an example. It is a feature that greatly improves the collaboration UX between developers and projects on d.o. Someone pointed out that is not equally easy on github.
@chx pointed to the patch workflow, https://groups.drupal.org/node/313068#comment-953888, and specifically that the current one is community based and that will probably be lost on github.
For me being able to quickly spin up a Drupal instance with a patch on simplytest.me has been the best productivity improvements since I first joined the community. Its also the best improvement ever been added for non-coders to help testing things incredible easy.
From my point of view, it isn't the repository that drives development of Drupal - it is the issue queue!
The IQ is also where the strength of our community lies, its where users of all roles can meet, discuss and collaborate on things.
Michael Keara, with a little help from me, presented a session at DrupalCon Portland about the "Love and hate in the Issue Queue garden". Or, as I called it "Our Drupal Workplace: The Issue Queue" http://www.tsvenson.com/blog/2013/05/our-drupal-workplace-the-issue-queue.
Maybe moving to github solves some short term problems for code production. But, from what I have read in this discussion I have a bad feeling a lot of the current cross role collaboration might be lost, resulting in the risk that developers will become more isolated from non developers.
Is that really what we want?
I'm not saying Github will
I'm not saying Github will solve all our problems but I find the current patch-centric workflow difficult. If you work with an issue that is touched by a lot of people it becomes very difficult to track what has changed, where, and why, even if everyone is experienced enough and being very thorough and creating interdiffs.
simplytest.me
I have absolutely fallen in love with simplytest.me. Just to be able to, withing minutes after a click, have a purpose built Drupal instance with the patch up and running is amazing and incredible productive for me as a user.
Maybe something similar can be done on GH, but will I then be able to follow the patches evolving as easy as I can today?
Or be able to, with the help of dreditor, also have a nice code reviewer a button away?
I have personally no problems setting up my own patch testing locally, but the massive UX and productivity improvements thanks to simplytest.me is bar none.
Plus it allows anyone that can install drupal to test patches with no code experience needed whatsoever. And that for me is the biggest win of them all!
I remember when I first
I remember when I first became involved with the community. Things were confusing. This seems somewhat more confusing, and it may make it more difficult for people to get involved. I do like the idea of an evidence based approach, and I think that measuring something around increased contributions is a good idea.
I Am concerned from an accessibility point of view. Github's UI is not particularly accessible, and our community has no control over improving that today, or preventing it from getting worse tomorrow.
ideas which not only
If you mean that moving d.org from CVS to git a few years ago was a huge task, and the work that went into that is pretty much thrown away if we move to github, then I think you have a point.
.
Its not my intent to blame anyone for the lack of tools ... but as someone who's community niche has been working to improve those same tools (or keep them running, in the testbot case) so that other volunteers can focus on their priorities, I reject the argument that "it can't be done because it hasn't happened yet" as conjecture; and point to the recent governance initiatives, formation of the drupal.org working groups, and even this "2014 roadmap brainstorming" exercise itself as signs that there ARE people listening, and that they are both able and willing to influence change ...
... well, willing for now at least, as long as the implementers don't allow themselves to become demotivated by the community's constantly negative messaging regarding the problems that they are trying to solve; and mob-like momentum behind ideas which not only disregard their efforts to date, but also end up creating a greater body of work for them in the future.
Hm. Not crazy about this...
IMO anything that moves us away from the standard Github development workflows only creates "Drupalisms" that then make Drupal harder to contribute to and develop for, and end up negating a lot of the original benefits of this proposal. :(
Is there a way to address this concern without resorting to our own custom "process hacks"?
Druplicon sees the world
How about this: we create a bot (I'll call it Druplicon for now). Then the workflow would be like this:
1. Contributor Caitlin posts a PR, gives Druplicon write/admin access to her forked repo.
2. Reviewer Rodney sees a few minor typos, and decides to fix them. He posts a comment with some sort of special syntax (@access maybe?).
3. Druplicon "reads" Rodney's comment and grants him commit access to the fork.
4. Rodney fixes/commits the typo, possibly via GH's web UI.
5. Rodney's new commit shows up on the PR.
The difficulty in bouncing a
And that is how the majority of issues are fixed: patches are bounced around.
I've just done a quick scan down the top of the core 8.x log, and most commits have more than one name in the credits. This is our main workflow, so we'd better be sure we're either improving it or at least not making it harder.
+1.
+1.
Yes, I know. But if the
Yes, I know. But if the Bluecheese maintainers ever do want to move to git/github, they can.
So it sounds like what you're
So it sounds like what you're saying is regardless of what support system is chosen (DIY or StackExchange or something else), the key to users getting useful answers is to make sure there's tight integration of that solution to whatever website the developers hang out on, so that the people who can help are aware there are questions out there that need their attention. Is that a fair summary?
Drupal developers should spend time on Drupal
This is not true. Most developers are willing to contribute, they just don't want to spend time reinventing the wheel.
Most developers want to help to make a better system. Spending time on implementing tools that are already available somewhere else is not helping directly on improving Drupal itself.
Yet you came with a good argument in your blog: http://drupal4hu.com/node/371
However centralized discussion also can happen in GH when a pull request is opened. Although I think this point should be improved in GH to be ideal.
OK. The official answer if
OK. The official answer if 50min. https://github.com/travis-ci/travis-ci/issues/1362
Another problem with github's
Another problem with github's issues is that issue attributes (title, body, tags, assignment) can only be edited by commiters (the issue creator can only set and edit title/body). Anyway, I think many of these problems could be solved with a bot sitting in the issue queue (with commit access so it could set attributes),
On GitHub
To be clear: I think there's a lot of benefits to moving to GitHub. I think there's a lot of risks, too. (The difficulty in bouncing a patch back and forth between people ad-hoc is my biggest concern, followed by the relatively poor issue categorization tools.) At the moment, I am not sure what the balance is and whether GitHub is the Right Thing(tm) for Drupal.
What I am sure of, however, is that it's very clear that the rest of the PHP community has adopted GitHub as the de facto platform for software collaboration, as have many other communities (Rails, Node.js, etc.).
What I am sure of is that moving to GitHub would vastly decrease the cost of adoption for already-PHP-skilled developers who want to contribute to Drupal, because they already know the toolchain.
What I am sure of is that we owe it to ourselves to give GitHub a good long hard look, and see if we can make it work. Maybe we can't. That's fine, but we need to dig into it and figure that out, not just dismiss it out of hand.
And if not GitHub, then we should move to some new infrastructure that involves vastly less code written exclusively for Drupal.org. Open Source applies to us, too. Let's make less code in the world.
Organization
The "all over the place" problem can be mitigated somewhat by having a Drupal organization on d.o, and only "official" projects can live in that organization. That helps with namespacing (you can still "own" a module/theme namespace just as you do now), and we can manage handing over a project to new maintainer(s) without the "Wait, who's fork is the right one these days?" problem. Also, only projects in that organization will have any Drupal.org integration (whatever integration we decide that is). That is not identical to what we have now, but can help mitigate the problem you describe.
We could probably aggregate
We could probably aggregate job related events on g.d.o and display them in a block on the new d.o/jobs page.