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
https://github.com/spf13/spf1
https://github.com/spf13/spf13-vim/network
I don't actually show up there, because my forked changes have long since been merged. :)
Images
Except for images. However, I don't get what we need other uploads for. Patches/interdiffs are replaced by PRs, and images are supported. In the rare case that we need some other upload, we can upload it somewhere (Dropbox?), then link it.
Oh?
Oh? https://github.com/blog/1547-release-your-software
I think they are talking
I think they are talking about the opposite problem... if I'm the "spif13/spif13-vim" project, how can I tell when someone spins up a new fork to work on something so I have some visibility into it?
Also, if I'm a member of the usability, accessibility, multilingual, documentation, "architecture," etc. teams, how do I easily figure out what all the pending changes are so I can provide early feedback?
Centralization of releases
Centralization of releases will be kept at d.o
It is extremely easy to see
It is extremely easy to see what is a fork:
I have a strong preference
I have a strong preference for moving to at D.O. Powered QA:
I am fine if the drupal.org decides to use a service like stack-exchange, but I think a very basic QA that is integrated with issues and projects would be far more valuable.
Examples of integration:
- projects and issues tagged in this question/answer
- How many questions and answers tagged with a project (on the project page right under the issues block)
- Turning a question into an issue and an issue into a question
Public mode
My bad, I thought that was what public mode was for, but I tested it and it seems you still need an account first.
I agree with the criticism
I agree this is a HUGE pain point and I am one who built rocketship that is used as an issue board by many initiatives based on data pulled from drupal.org. I think the main pain point is the (a) lack of data API where those issues are exposed (b) the lack of interaction API to update issue data from a 3rd party system (c) the lack of such 3rd party system that could be integrated using such APIs.
So I fully agree about the pain, I have no good idea ATM about the solution. I would need a couple days at least to go look for options on what is available, how can one integrate with 3rd party APIs, etc.
Keep release tarballs on d.o
Localize.drupal.org is currently dependent on the release tarball system to extract and parse out translatable text. Decentralising that would be an issue, but sounds like that is not the proposal here. Just wanted to make that point so its considered for similar ideas.
Nice to meet you too! Public
Nice to meet you too! Public repo's are currently not in GitLab but we might add them in the near future. Drupal planning to use GitLab would certainly speed this up :-)
This is actually a good
This is actually a good point... improvements made to Gitlab would help benefit the larger open source ecosystem using Gitlab as a whole, as opposed to improvements made to Project* module which only generally benefit Drupal.org.
Though I'm somewhat dubious about us being a major contributor there, given that most people don't contribute to our current set of tools, which are written in PHP and not Ruby. Still, there are a lot of tinkerers out there and we might be able to help. :)
Hi, sytse! Nice to meet you!
Hi, sytse! Nice to meet you! :D
Yes, Drupal.org currently hosts around 30,000 public repos and 28,000 developers. Our needs for private repos are fairly small... I can actually only think of one or two we would need, all for "actually running the website" type of stuff.
Centralized Project Listings
It was already in the proposal. I've edited it making it more visible:
https://groups.drupal.org/node/313068/revisions/view/657148/657198
Had a hunch that would be
Had a hunch that would be needed.
The risk then is it will alienate a large portion of the community that will question having to create a github account for participating. Just creating the account is probably the smallest obstacle compared to having to learn a very developer centric platform that they have little, or no, use of in their own roles.
In my book that is a huge risk and one that will distance developers and users instead of improving collaboration.
I agree with jhodgdon on many
I agree with jhodgdon on many points here.
Can we solve it hosting issues on d.o and using github's API?
I'm not familiar with their API, then I have no clue.
I wish I could upvote this
I wish I could upvote this more. It would be a huge step forward in my opinion. I think there was also a suggestion on here for a module rating system that would be cool to see integrated with this.
wildkatana What were some of the barriers you were up against other than time? Could you list them in the summary under risks?
GitLab can be configured to
GitLab can be configured to point to external issue trackers, see https://github.com/gitlabhq/gitlabhq/blob/master/config/gitlab.yml.examp...
Other than auto logging into
Other than auto logging into support channels what is the major advantage to this over just recommending http://webchat.freenode.net with a quick video describing some of the IRC basics?
I think a small video tutorial describing getting support on IRC would be much more beneficial than creating another tool on d.o that we would need to maintain.
not sold for issues on GH either
To be honest I have mixed feelings about issues on github. I see advantages and also many drawbacks both in d.o and github issue queues.
Discussion with code is a great feature, but maybe it could be implemented it in d.o using their API?