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
Same reason people fork
Same reason people fork downloaded modules and don't post patches?
It takes about 5 minutes to make a patch too.
It's not that long at all
It's not that long at all since d.org got a new theme. And that took a VERY long time to design and implement (IIRC the ball started rolling back at DrupalCon Szeged). So I think there are other improvements we should focus on before we turn to the d.org theme once again.
Though making the current theme responsive is very definitely needed!
I don't see why somebody
I don't see why somebody would fork, then not send a PR. Sending a PR takes less than 5 minutes (plus however long it takes you to give it a title and description, which are pulled from the commit if there is only one commit).
Good idea, added image.
Good idea, added image.
There were a lot of
There were a lot of discussions around new designs within the Prairie Initiative - https://groups.drupal.org/node/137914
On one hand, I like the idea
On one hand, I like the idea of reputation, so irregular users who don't know anything have a better idea of who to listen to. But on the other hand I worry about the formation of cliques, and the inherent politic-ism that comes along with it. With no visible reputation system, each post essentially gets evaluated on its own merits.
I'm not familiar enough with
I'm not familiar enough with the issue queue on Github, but I think you cannot have the full range of states like "needs review", "needs work" etc. as we have on drupal.org. I need those states to efficiently work with the issue queue, that's why I proposed integrating our powerful issue queue on drupal.org with the Github API to push/pull whatever information we need from pull requests for example.
I might be wrong though, not sure what can be done on Github and what not.
Gitlab
I send an email to gitlab, asking to chime in.
Those metrics are misleading
You forgot to count the closed PRs. Rails in reality had over 12 000 pull requests and the real number of forks is unknown because deleting a repo is not hard and so the number of deleted forks is unknown.
Interesting. See also this
Interesting. See also this comment https://groups.drupal.org/node/312978#comment-952998 which talks about a Drush extension for managing patches. Could be very similar to what's proposed here, though of course this would affect everyone not just those who use Drush and know about said extension.
If I'm reading this properly,
If I'm reading this properly, I guess the main reason to do this would be to not be reliant on an external, commercial entity for such a critical piece of our project's future. Or is there anything in Gitlab's feature list that Github doesn't have? It might be easier to start from there, so we understand what we'd gain by incurring the ongoing costs you note down below (hardware, sysadmins...), which of course wouldn't be present with the Github option.
Maybe in-line some mocks in
Maybe in-line some mocks in the idea description? This is a really cool feature but I'm not sure people understand it from just the title.
Also, given the support this idea is getting...
Are there people out there who are willing to volunteer / fundraise / research / develop for this effort? If so, please add your info under the "Are additional resources available for discovery/implementation?" part of the wiki page.
+1 Reading a
+1
Reading a "commited=>fixed" comment on the issue is somewhat useful, but not ideal. It does not tell you wether the fix is in -dev, 1.x or 2.x - much less so when looking at the issue a few months down the road.
To be able to track the issue/patch to specific commits/branches would help clarify the status quo on the issue.
Klausi, I think...
Or whomever wrote:
...in the wiki summary.
who's you
webchick, who are you addressing your comment to?
In case it is me, I think moving issue queue as well is a good idea, and if we go the gitlab route, we might even easily migrate everything as well. Gitlab provides the option to use an external issue queue, but it doesn't mean we have to use it.
One problem we probably face when moving is that we might loose the link between the commit message and the nid of the issue.
Why not issues as well?
Would you be able to provide more justification for why you think we should move only the code repos to Github and not also the issue tracker?
Since one of the stated benefits of this proposal is "Lower barrier for people to contribute" (which I agree with), it's odd to me that we would then choose a non-standard collaboration method for those repos, and thus largely negate that benefit.
In other words, people who use Github use the whole enchilada: the code repos, the issue tracker, the wiki pages, etc. They're used to collaborating on other projects on Github that way. If they had to do something different for Drupal, and go get a separate login in some other site and fill out forms they've never used before, etc... don't we lose a lot of the advantages of doing this in the first place?
Are there any mockups or such
Are there any mockups or such that you could reference here to get a better idea of what's being proposed here? I think everyone would vote for "better" anything, but it'd be nice to know a bit more where my + is going. :D
I've actually already been
I've actually already been intending to contribute to some of this, for example AJAXifying the comment form. Then I found out about this group today, so I thought I would post this.
Thanks for responding here;
Thanks for responding here; glad to see some forum users in this discussion! :)
Can you please edit the wiki page to make sure your points are enumerated in the "Risks" part of summary up above? Ideally, people coming into these idea posts could understand the full picture without having to read all X comments.