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
The current D7 Bluecheese is
The current D7 Bluecheese is built to be responsive from the ground up. It's built on Sass and Susy.
Shall we move to GH for code
Shall we move to GH for code repository, Drupal.org should still be the central place to look for and find contribs. Look how the Node.js (npm), Ruby (gems), jQuery (plugins.jquery.com) or part of the PHP (packagist.org) communities handle having code on GitHub (or other place) while still providing a central registry.
Discerning the "canonical" package of a module and ensuring uniqueness is handled at the registry level (ie. drupal.org in our case), not the repository one (ie. GitHub in the context of this discussion).
Having http://github.com/drupal/phingdrushtask would not much make sense, I'm the maintainer of this tiny project, not the people managing the Drupal oranisation on GH. There is no need to involve anybody else when it comes to managing the code repository. So if we move to GH, the code should be in https://github.com/pbuyle/phingdrushtask. Off course, https://drupal.org/project/phingdrushtask will still exist for me to manage releases, project description, etc.
Yes,
Yes, https://github.com/drupal?tab=members is already controlled by chx and mikl.
They could add some administrators like https://groups.drupal.org/node/142454 to that github group who would create the repositories and assign access to applicants.
I started but
I do not actually know how much you actually want to implement. Differential seems to be a bit heavy for just a patch review tool, no? I am not sure.
Being able to discern "canonical" repo is indeed very important.
I'm dumb, but... could this be resolved by http://github.com/drupal/X being the canonical repos? For example, it's really obvious that https://github.com/symfony/HttpKernel is the canonical version and https://github.com/chadfennell/HttpKernel is not.
Sorry
Ooops! Didn't realize I was logged in ... will update with screenshots.
Don't understand visibility concern w/ PRs...
Yeah, I'm not totally clear on chx's concerns. PRs seem to show you the visibility of the evolution of discussion way better than our current issue queues.
Just showing https://github.com/FredrikNoren/ungit/pull/75 and https://github.com/BBC-News/wraith/pull/16 as a couple of random examples that I found:
1) Whether or not testbot is passing the latest "patch" is built into the "issue summary," rather than you having to go digging for it.
2) Visibility into who is following the issue, not just how many.
3) Images are inlined automatically. This is actually easier for non-technical users than hand-typing HTML tags.
4) Visibility into interim commits that happened between the original post and its comments. We currently get zero visibility into interim commits with Drupal.org sandboxes, just a huge patch and a merge at the end.
5) It's clearly noted when/if an actual merge happened, as opposed for looking very, very carefully for "Committed and pushed to 8.x" type strings.
6) You can add a "Line note" for code reviews (similar to Dreditor), but line notes about outdated "patches" get collapsed by default so they don't sit there cluttering the list! That means we could most likely drastically cut down on 100+ reply issues.
7) Seeing peoples' faces makes for a much friendlier place to discuss things than tiny blue nicknames everywhere.
All in all, I'm not clear at all where the visibility problems get introduced. I think what chx is saying is when you click the "fork" button, but before you click the "pull request" button, no one has any idea what you're working on. But that's true of code i have on my localhost, or code I'm tinkering with in a Drupal.org sandbox. At least with Github it seems like you'd have the option of viewing a list of them (https://github.com/symfony/HttpKernel/network) (although I can make absolutely no sense of Github's network graph :P~).
Yes, but my point is to make
Yes, but my point is to make it really clear there are things that we would still need to maintain.
AFAICT drush can lookup and resolve dependencies. Not sure what you mean about that.
I don't think "check the package manager" is a "piece of cake" for the average person who has downloaded Drupal. Are you saying we should concede that we're a geek only tool? My concern is basically around the case that someone searches on a non-drupal.org search engine and finds a random repository on github and thinks it's the real one when in fact it isn't.
beep beep boop robot noises
Hey everyone,
I'm the Phabricator lead, I found this through vanity Twitter searching. Feel free to get in touch with us if you have any questions. I'm usually active in #phabricator on FreeNode during daylight PST hours, or there are other ways to drop us a line here:
http://www.phabricator.com/docs/phabricator/article/Give_Feedback!_Get_Support!.html
Or you can just tweet about it I guess and I'll find it sooner or later.
Evan
@webchick I see your point,
@webchick
I see your point, but what concerns me is @chx description of the workflow in https://groups.drupal.org/node/313068#comment-953888.
For me his description sounds like the changes, patches in the d.o IQ, wont be as visible and easy to find and follow on github. Now I can simply scroll through a specific issue and see the patch evolution in it. However, again if I understand @chx's comment correct, the same patches might very well be in forks and more hidden in commits and PR's.
If that is so, then a lot of users that today participate in our IQ's will have a much harder time doing so on github.
I think it is important that we really consider the balance between just how much a move would improve the UX for developers with how this would change the ability for less code oriented users to participate and collaborate.
You can find some screenshots
You can find some screenshots and a quick overview on: http://phabricator.org/
I would propose that d.o
I would propose that d.o still maintain a package system of sorts along with updates.durpal.org etc. Look at examples such as Ruby Gems or Node's NPM system for a good example of how a VCS agnostic package system could work. It still allows tools like drush (or gem/bundler, npm) to search, install, and lookup dependencies (which d.o doesn't support yet).
Finding the canonical repo is a piece of cake as well, when you can check the package manager and see where it points.
The simplytest.me integration
The simplytest.me integration argument feels like somewhat a red herring to me. You need to use a Greasemonkey script (Dreditor) in order to have simplytest.me integration in the current issue queue. Adding it to Github's issue queue would be the same.
Just out of
Just out of curiosity...
Let's say that we moved wholesale to Github. Including release management/tarballs. This would undoubtedly cause all kinds of work to have to happen in release-using projects such as localize.drupal.org (also Drush PM-* tools, Update Status, Simplytest.me, probably some others I'm not thinking of), because obviously you'd be talking to a completely different system than you do now.
But, if that work were to be done, and assuming it was done on open sourced Drupal modules like it is today, would that then mean that general Drupal websites could set up their own Drupal-powered translation UIs (and update checkers, and demo frameworks, etc.) that talk to their custom projects stored in Github? If so, that could potentially be a place where we could get much more people collaborating on those tools than we currently do, because they'd be of general usage beyond just Drupal.org.
+1 for Jay's reservations
I agree with everything Jay has written here. I'm not a member of SE, and haven't got any motivation to learn how to. I'm already a member of drupal.org, and enjoy helping out there from time to time.
Have I remembered correctly - sometimes posts on SE seem to get closed down because they aren't correctly laid out for that part of SE. IMHO it would be a mistake for Drupal to let go of moderating its own forums, allowing us to develop our own policies that suit Drupal.
Yeah, I think the interest of
Yeah, I think the interest of Drupal users will make GitLab better. There is also interest of Fedora in using GitLab, and we hope for more open source projects, see http://blog.gitlab.org/packaging-gitlab-for-fedora-a-gsoc-2013-project/
Great, please email
Great, please email support@gitlab.com if you need any help.
Currently public mode only
Currently public mode only gives you a clone url and some basic info, not everything that people expect. For an example see https://gitlab.com/public
Great idea and...
.... and very easy to implement. Add a link to somewhere to
http://webchat.freenode.net?nick=$username&channels=%23drupal&prompt=1and be done. Alternatively, you can even iframe it on drupal-webchat.org or somesuch. Absolutely minimal custom code.Can you flesh this out with
Can you flesh this out with screenshots or something? I'm not familiar with Phabricator, and the links take me to a login page.