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!
Recent comments
100% in agreement with moving to GitHub
I personally think "dogfooding" is rarely a good idea. I've always been very unhappy with the workflow on D.O for contributing. I just don't like the "patch" workflow, and I learned that workflow before I learned the Git/GitHub workflow. For me, it's so much easier to fork, edit, and make a pull request. I can still pull in changes from master meaning I can take my sweet time working on a large pull request.
Sometimes we have to accept that dedicated tools (i.e. GitHub) are just really good at what they do. A huge part of Drupal contributions is integrating things which work really well at what they do... like Disqus for commenting, Recurly for subscription management, etc. I think we should look at this as a strength of our community.
Back to the original analogy, I think moving to a GitHub workflow is like eating our own "drupal flavored" dog food. The Drupal part comes with how we would integrate with GitHub and that shows Drupal's strength and helps the community contribute.
If we did that today, Drupal
If you're honestly saying that, with a dedicated effort, it would still take over two years to port Drupal.org to Drupal 8, I'd suggest that we've made some big mistakes with D8 core. Instead, I'll simply file this away under speculative exaggeration. ;)
If we keep the jobs spread
If we keep the jobs spread out on gdo, I would appreciate a "hide all jobs" checkbox. :)
The existing issue on this is
The existing issue on this is stuck on D7 upgrade and a little debate on external services https://drupal.org/node/957320
I think a path to completion could be:
.
That's a dreditor thing.
Totally on board with this
Totally on board with this just not for D8. Let's get that into the wild and get this structured properly with the next release cycle so everyone can be on board with it. I believe making d.o upgrade the same time as release will also result in a shift in priorities. For anybody that has ever tried to upgrade a site from one major Drupal to another knows it is VERY painful and costs a lot of money. We see that now with drupal.org as it is. Imagine what we are doing to our biggest Drupal users. I see this resulting in a much less painful upgrade path for all of our users and just make Drupal better. Right now upgrading core versions is the dirty little secret we hide from our clients because if they knew the actual costs going into it they may reconsider using Drupal for their platform.
Yes, and this sucks. See my
Yes, and this sucks. See my comment about a bot.
The core release cycle is
The core release cycle is definitely about core, but could be used to help inform a guideline for contribs.
The other page says:
So, are you basically asking for a way for people to say "I follow that set of guidelines" ? Pinning down at least the basics of the guidelines will make it a lot easier to focus on the proposal (how does someone opt in? does search filter projects based on this facet? etc.) rather than an unknown standard.
OK, makes perfect sense! I've
OK, makes perfect sense!
I've updated the title to try to make the goal broader and implementation details more clear. There are probably other solutions, but I agree that "making search better" could be a good place to spend some time, eg.:
i like this idea
many many many sites have a "support chat" feature. if we had a call to action that opened up an IRC box to #drupal-support i think that would be pretty slick
We used to
We used to do that up until Drupal 5, maybe Drupal 6. Then we went into a cycle of making much larger changes to core, which made upgrades more difficult, and Drupal.org started using more than just core+project*. A Drupal core update today takes way more work than it did 6-7 years ago. when we still did that.
If we did that today, Drupal 8 would not get actually released until 2016. No, we're not doing that.
Added to summary
I added a link to the summary. Although as a note, the proposal here says at one point that we don't want to use Github's issue tracker... I think it would be pretty difficult to host the code on github and not have at least some issue being hosted there, which could lead to fragmentation if we are trying not to use their issue tracker.
External issue tracker would be good
I posted on the Github thread about the specific problems with Github's issue tracker (as did others). Basically it lacks most of the features of most other open-source and commercial issue trackers, such as dedicated meta-data fields for status, severity, category, etc. (which IMO are absolutely essential. the ad-hoc tags that Github's tracker support are not a replacement), and the ability to upload files.
Rather than spending time developing another issue tracker system or contributing to this one, the ability to use an outside tracker would be better.
Assuming that we no longer want to retain the Drupal-based Project Issue, Bugzilla would be the logical choice. Some people don't like it, but it at least is adequate and actively maintained, and many many other large and complicated open source projects use it (Mozilla, Linux kernel, etc.).
Thanks Garrett. Yes, I know
Thanks Garrett. Yes, I know its a kinda crazy idea, but I am serious about thinking it can actually work and be greatly beneficial for us.
I've expanded a bit on it in a blog post I just published. Welcome to check it out on http://www.tsvenson.com/blog/2013/08/dogfooding-our-drupalorg-infrastruc...
If we set the criteria that a
That's kind of a crazy idea, but I like it. I think we would need to open up D.o repos and databases and such to more than a handful of developers in order for that to be feasible, though.
Actually, I just discovered
Actually, I just discovered that if you do the generic full site search and then filter the results by module, the "Most Installed" sort option does become available but unfortunately it's not the default and it wouldn't be obvious that the sort options have expanded when you chose a filter. A little UX tweaking would be useful here. i.e. when clicking the option to filter the results by module, automatically sort by most installed.
More people finding drupalmodules.com functionality useful
More people finding drupalmodules.com functionality useful, also a related discussion here: https://groups.drupal.org/node/312828#comment-953238
Finding drupalmodules.com useful
Finding drupalmodules.com useful, you can vote : https://groups.drupal.org/node/313353
I agree with you as to the
I agree with you as to the usefulness of drupalmodules.com and am similarly discouraged that it’s no longer up to date, but I think it’s important to have a degree of separation between reviews of modules which are purely subjective and their technical aspects. As such, I’m not in favor of reviews on drupal.org. Opinions filter their way into discussions about the modules anyway, so review-like information can be gleaned if a module has enough feedback. I DO agree that a lot more could be done to make finding the right module easier on d.o as well as keeping track of them as with the favorites on drupalmodules.com.
Search seems to be a very hot topic
This is thematically related to https://groups.drupal.org/node/313013