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
Ease of Use, Ease of Modification
Implement Drag & Drop Wherever Possible
Look for ways to simplify theming, sub-thememing and nodule modifications for non-coders. This should be done for D7 and D8.
Emulate sites like Pinterest and NeonMob where inputs and changes are extremely simple, auto save upon drop, etc.
What are the benefits?
Much wider audience
Overcome current image of too steep learning curve, unfriendly UI, closed secret club
Gain the input of non-coders, business people, artists
Make site design faster, prettier, more controllable
Focus on the big picture rather than IT details
What are the risks?
Time investment, cost, UI expertise, PHP dev hours, resistence from current Drupal experts
How can we measure the impact of this idea? (metrics)
User Growth, Changes in site design styles, PR coverage, General public awareness, User Demographic diversity
Who directly benefits from / will use this improvement? (target audiences)
Everyone involved with using Drupal, non-coders approach it, experienced coders work faster.
Large corporations will adopt it more quickly; it would lower the entry cost of using Drupal.
Drupal needs to be opened up to a much wider audience to help it grow and receive the intelligence of the many who are afraid to touch it or get quickly frustrated and go to wordpress or other
Even this form is designed for only those who understand HTML
Are additional resources available for discovery/implementation? (volunteer effort, financial backing, etc.)
not sure, whomever has a vested interest in Drupal growth. Drupal assoc?
Yep, this is definitely a
Yep, this is definitely a good point. One of the big advantages of the issue queues is they look/feel a lot like the forums, which look/feel a lot like the download pages, etc. It makes crossing the boundary between "user" and "developer" and "documenter" and so on quite seamless, and culturally has brought us many advantages, like people who are mere "users" actually contributing very salient points on developer discussions. Using Github for developer collaboration would create a very strong barrier there, both physically (in terms of requiring another login, look and feel being totally different, etc.) and also mentally ("oh, that's where the developers hang out. That's not for me.")
Ironically, part of that
AFAIK it was only one month, though possibly two, because the board was told we spent the entire year's D.o budget on not delivering a D7 upgrade and said essentially, "Woah, back the hell up for a minute." As the DA board has fiduciary responsibility over the community's money and how it gets spent, I see this way more as "performing due diligence" than mere "politics."
I'm going to disagree here, too. I think what you saw briefly was core developers who were completely burnt out during the D7 release cycle decided to work on D.o tools for awhile because they were so pissed off with the tools limitations that they couldn't stand it anymore. Once they got their itches scratched and some of their mojo back, they returned to what they came here to volunteer for in the first place: working on Drupal core.
If Drupal.org tools only evolve when core developers take time away from working on core, this is not a remotely sustainable situation. We have much to do, both process-wise and governance-wise, to ensure that a motivated volunteer has a much easier time of contributing to Drupal.org, and we are and will be actively working on that. But the DA owes it to the community to ensure that their development platform can evolve apace with the needs of the community without requiring volunteers to "double-dip."
Note: "Project" not "Project*" :)
Note: "Project" not "Project* " :) If we moved issue queues, release management, repos themselves, etc. wholesale over to Github, we'd just need the download listings, not the whole of Project* and Version Control API* and so on. That's still several thousand lines of "contrib but actually custom" code we'd be able to shift off our plates. I edited my comment to make that more clear.
We've yet to see if the D7 code base modernization of Project* results in more outside contributors. I'd like to hope that it could (that was, after all, the main justification in doing the refactor as part of the upgrade), but since the upgrade was so delayed due to that refactoring, all those people who claimed they were eager to work on these tools "if only they were on D7," all work on D8 now, so I worry that D7 is the new D6 in terms of "ewww, yuck." :\
Good summary ... but I think
Good summary ... but I think the "kill off several thousand lines of 'contrib but actually custom' code" argument in favor of the move is a bit of misdirection, especially considering the 'Project* is here to stay' statement which follows.
The foundation of the custom code argument is the frequently quoted 'pain of the D7 port' statement; when in fact, that pain was caused by the refactoring of Project* (which we don't get rid of in moving to Github), specifically to remove the several thousand lines of custom magic and instead rebuild it based on fields and contrib (making it much easier to maintain over the long run) ... maybe I'm just naive, but I haven't heard many complaints about the maintainability of our repository-related codebase.
If it happens we can ask them
If it happens we can ask them to get bi-directional oauth integration, or something similar.
I like this idea, but it
I like this idea, but it seems to be a complete new proposal.
Timing could be pretty
Timing is a critical consideration, but even waiting until after the D8 launch doesn't help things in this case. With all the concern that the scope of D8 changes risk alienating a portion of the existing community of users/contributers, this proposal also suggests a full-scale changout of familiar and long-ingrained workflows at the same time. Even if there was a strong focused (people) change management plan in place, things will seem very foreign very fast; and that double-whammy of disruption is going to be very difficult for the 'non core-developer' Drupal community to overcome.
The first has very little
The first has very little discussion. This is admittedly a less painful process in GitHub when you can just commit accept changes. I can't think of a single core issue I've been involved in that's happened on in my 6 years in Drupal development. We barely even do that in 1 line doc changes.
The second PR you link wasn't even merged. The other was without any apparently discussion or related issue or review or feedback. This is better?
We haven't yet managed to
Ironically, part of that delay is that fact that D.O D7 development was frozen for multiple months so that people could evaluate other options ... such as 'moving to github'. Now, a large majority of of the arguments for a migration are driven by frustration with outdated tools and workflows on drupal.org, and "look how hard it is to port/maintain drupal.org today" is one of the frequently quoted justifications ... even though i) the delays were just as much political as technical, and ii) as you pointed out, even if we did move to github, Project* isn't going anywhere!
Another aspect of those delays was a timing-induced resource conflict between the D.O upgrade and D8 feature freeze. No, that's not suggesting that all core devs should be voluntold to work on drupal.org ... but there were individuals with a vested interest in both priorities, who may otherwise have made larger contributions to the upgrade project.
Unfortunately, these angles are missed when waving the "Drupal.org is too much work, move to github!" flag. ;)
I added this to the wiki node
I added this to the wiki node at the top:
Unless I'm being stupid, this (very valid) concern wasn't on there already.
default, perception and the like
Sure, but also there's nothing that makes you do that. Your code already is on github and anyone might see it -- if they bother so, which they will not.
Currently the default is to share work in progress in form of patches. That's not the default with PRs, however.
In my suggestion to github, the workflow would be: when you start working on issue, github creates a branch in your fork (creating the fork as well if there is none) AND files a linked PR immediately so that all your changes are visible -- by default.
Default is important.
This was the biggest point I
This was the biggest point I was trying to make in the Google Doc but Larry more eloquently explains it.
yes, awesome, and yes. Some
yes, awesome, and yes.
We should probably work under the assumption that it isn't temporary and build a solution we're happy with and can maintain. Especially, if as you say, project.module isn't going anywhere. Otherwise we're boxing us into the same problem in the future. :)
Similarly, as the world moved
This is a possible risk that counters the maintenance advantage of moving to Github: if/when the next big thing comes along, does time have to be expended moving to that? At least with keeping everything on d.o the best features of each newly hyped system can be integrated into drupal.org's own.
Another risk: how stable are Github's APIs? Assuming tight integration between d.o's project tools (issue queue and such), would there be any cost savings if they're like Facebook and changing their APIs all the time?
AFAIK, yes that's true, and
AFAIK, yes that's true, and no there isn't. Unless we were to implement a Github single sign-on solution on Drupal.org, but it'd only work in the Github -> Drupal.org direction.
Timing could be pretty
We haven't yet managed to launch the Drupal.org D7 migration, despite starting it over a year ago, so fret not: I don't think we're in any danger of doing any major undertaking to our dev tools until D8 is out. :D
Should, but if past experience is any indication, aren't. But your point about making it easier to work on the site should they so choose is definitely heard, and will be a big priority for us in 2013/2014.
This is something I've been thinking about a lot, too, the past couple of days. Some kind of "hybrid" interim solution that could allow for people to work wherever they're most comfortable, while we wait and see on Github's issue queue / "swarming" tools and how/if they mature over time. This would also allow us to track how popular Github really is among our contributors, so we were basing this decision on data rather than gut feeling/interpretation of (at times) emotional arguments.
Thanks Angie!
Thanks Angie for that. That's some useful information and there's a lot of knowledge in that spreadsheet.
First I hope we're careful to not "cut off the nose to spite the face" as the saying goes. Especially as we're dealing with a lot of frustration going into release and people are just starting to hit their strides understanding git and working within the tools we have. Timing could be pretty important here as swapping that between now and D8 IMHO opinion could be disastrous.
On thing I'm not sure is visible in this breakdown is something I heard in several comments offline was that d.o is actually more powerful then people give it credit for. Also many of the the con's have discussions and proposed solutions dating back to the git migration.
We've got aging tools, but we've got an aging site. There is a lot of site building talent in the community that's should be motivated to help improve our site. So as a first step it seems reasonable to look at things we can do to make our lives better on parts of the infrastructure that aren't going away. We should see what we can do about lowering the barrier to contributing and along the was look at things we can do to empower people to use their own workflows since that's the real power of git.
Along the way, maybe things like hooks for maintaining you project in GitHub or other external git repository. Pull requests from any external repository too. Things like that really give us more power and really are the power of git. In that vein looking at only GitHub is actually near sighted and limiting on our part.
Yep, this is correct, IMO. It
Yep, this is correct, IMO. It also doesn't get us away from the project approval process.
so hard to stay off my soap box
Awesome!
That really helps clarify the workflow differences between the two. I think I'll just add a link to this comment since I can't really see a way to condense it without losing info.