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
Visibility into who is
That is not the followers; those are just the people who have commented. We can't even tell how may followers we have.
Dots are commits. Horizontal lines are branches. Arrows represent parents (of commits).
There's no easy way to use
There's no easy way to use Project and other Drupal.org tools for private purposes. It's so hard to install a replica of d.o. project management tools and it's so specifically designed for Drupal project that nobody bothers to try it unless they are really seeking to contribute to d.o.
non-review patches Do you
Do you mean do-not-test patches, or something else.
I don't think this is that common, so an occasional inconvenience (upload to somewhere else) I think we can live with.
Off head...
we attach spreadsheets, text files, non-review patches...
Documenting Drupal.org vs. Github features
Seems like discussion has now shifted to the level of individual features. This is great, but I can't keep up with all the discussion here, and there's not really space for it in the issue summary.
I made this spreadsheet https://docs.google.com/spreadsheet/ccc?key=0AusehVccVSq2dEtuWm1JQ1ZSV1Z... to capture this information. I made an attempt at filling out some things, but it's open to all to edit, so please help fill it out!
I'll add this to the proposal summary too.
There's a fix for that:
There's a fix for that: https://github.com/jeresig/pulley
This package system sounds
This package system sounds like it might belong in its own proposal, since we could do that regardless of moving to Github or not, correct?
It doesn't solve the problem
It doesn't solve the problem raised by @joachim
Not everybody has the time/energy to report issues. Telling someone to close and reopen in another place is in no way good as just changing the value of a field.
There are many cases which someone opens an issue and even the maintainer thinks that the issue really belongs to his project, later researching he later moves it to the appropriate one.
Closing and reopening would lose this history in the fist opened issue.
Responsive Bluecheese
Responsive Bluecheese unfortunately isn't part of the D7 launch, so this one is very much still on the table.
That said, we'll probably do it regardless of votes. :) But show your support anyway!
Drush can only resolve
Drush can only resolve dependencies after downloading each package. For instance http://updates.drupal.org/release-history/views/7.x does not list CTools as a dependency.
In contrast the Ruby Gems API actually has a feature that provides a gems dependencies via the API, for example: https://rubygems.org/api/v1/gems/rails.xml. Or something like http://registry.npmjs.org/express for NPM. I can't tell much about Packagist and composer at this point but I bet they offer similar options, since the dependencies are listed on each package page.
As far as determining the canonical URL of a package, I don't really see how that will be any different than it is now. I personally have several forks of Drupal.org projects that I made years ago for packaging purposes and no one has ever complained about those. Nothing is currently stopping me from starting my own Drupal Views module on Github now either, we just trust users to download their modules from Drupal.org and rely on Drupal.org's pagerank to ensure they end up in the right place.
More robust
In the normal GitHub flow, you get a merge commit when you use the "Merge this now" button, even if a fast-forward merge is possible. That means the history accurately reflects the way the code evolved. One commit per issue is actually bad: It means you get 500 KB commits that are utterly useless because they change one API, implement it in 4 out of 12 places, fix 17 bugs, and correct 8 documentation issues "along the way". That belongs in 30 separate atomic commits, not one massive unreadable commit.
It also more accurately reflects the work that went into a patch; currently, "rewrote the entire forum module to have new features for the first time since before the US invaded Iraq" gets the same single mention as "added a missing period to a comment". That's not an accurate picture. :-)
You can also rebase or do squash merges if desired. I know Fabien often does that for Symfony commits, or asks people to rebase a branch to remove flailing about so the history is clean before he merges. We can discuss how we want to approach that.
Really, the "one issue per commit, totally linear development" is an artifact of a 12 year old CVS-enforced workflow. It's not an accurate representation of how Drupal works anyway.
"user files an issue core,
"user files an issue core, but it's a contrib problem. Maintainer moves the issue to the right queue."
-> i believe the maintainer would ask close the core issue and ask to create the issue within the contrib module
"what appears to be a code bug is in fact missing or erroneous documentation. Maintainer or reporter reassigns the issue's component."
-> the github issue queue allows to tag issues. by default, the following tags are provided:
bug, duplicate, enhancement, invalid, question, wontfix
the available tags can be customized by the project maintainer(s).
i think those are valid options.
still, it seems like the tagging issues option on github is limited to project collaborators
Some common d.org issue queue
Some common d.org issue queue workflows:
How do we do things like this on github?
Great
Very interesting software!
Maybe opening the example links to everyone without asking for login would help to get to know it better.
I'm curious about what Phabricator can offer compared to the other proposal of moving to github: https://groups.drupal.org/node/313068
But then when the maintainer
But then when the maintainer merges in the pull request, doesn't that mean they merge in a whole other branch? We use a single commit per issue -- it sounds to me like we either:
I would be willing to help
I would be willing to help with this.
Not eligible
CTR is not under control of the Drupal.org Software Working Group so would be ineligible as a proposal. Last published maintainers of the site are at http://certifiedtorock.com/blog/certified-to-rock-groupies.
.
I found a current discussion topic Q/A that has 3 examples: http://meta.drupal.stackexchange.com/questions/2375/do-we-need-to-relax-... .
It looks like the consensus in the comments is that the SE rules are fine as-is. I then see that there is no possibly way that someone could ask support questions commonly answered in the "Before You Start" forum on drupal.org because they would never fly by these rules.
Some of the arbitrary
Some of the arbitrary community moderation on Drupal Answers has discouraged me from joining and participating.
Edit: I didn't see your edit before I replied.
Moderation on a SE site is
Moderation on a SE site is handled by the community, and the rules are defined by the community. Off course, you have to learn that in order to properly use a SE site. But that just like learning the rules of a forums. With my little experience, I would say that rules are needed in order to maintan qulity of both questions and answers, but I never saw any for d.o's forums (ok, I had never look for them).
In order to identify if the existing Drupal Answer's policies are an actual issue, it may be useful to identify some good Q/A posts/threads on Drupal's support form that would not ne accepted on Drupal Answer.