Recent comments

Events happening in the community are now at Drupal community events on www.drupal.org.

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:

  1. Review the list of submitted proposals and "vote up" and/or comment on ones that speak to you.
  2. If you don't see your idea reflected, propose your own ideas using the idea template.
  3. While we want to hear about everything that's on your mind, we're especially interested in small, but impactful ideas.
  4. 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

jrowny's picture

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.

jthorson's picture

If we did that today, Drupal 8 would not get actually released until 2016.

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. ;)

Gaelan's picture

If we keep the jobs spread out on gdo, I would appreciate a "hide all jobs" checkbox. :)

greggles's picture

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:

  • Enable the feature on d.o d7 only
  • Work to make images work on subsites

.

Gaelan's picture

Once you have attached the image there is a handy [embed] button that does the job for you.

That's a dreditor thing.

haydeniv's picture

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.

Gaelan's picture

Yes, and this sucks. See my comment about a bot.

greggles's picture

The core release cycle is definitely about core, but could be used to help inform a guideline for contribs.

The other page says:

The guidelines below are for Drupal core. Some maintainers of contributed modules and themes might choose to provide alpha or beta releases or release candidates of their projects (though this is not required).

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.

greggles's picture

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.:

  • Public metrics for the most frequently searched keywords (including the number of results that were found)
  • A "were these results helpful?" button with yes/no that someone could submit and, again, a public page that lists the search terms with the best/worst ratings
mheinke's picture

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

Crell's picture

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.

jhodgdon's picture

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.

jhodgdon's picture

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.).

tsvenson's picture

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...

Garrett Albright's picture

If we set the criteria that a new Drupal Core major can not be released until the d.o infrastructure runs on it, then it will change peoples look and motivation on all of the above. Including motivation to work on the contrib modules d.o uses.

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.

leehunter's picture

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.

Anonymous's picture

More people finding drupalmodules.com functionality useful, also a related discussion here: https://groups.drupal.org/node/312828#comment-953238

Anonymous's picture

Finding drupalmodules.com useful, you can vote : https://groups.drupal.org/node/313353

grabby's picture

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.

Subscribe with RSS Syndicate content

Recent comments

Group organizers

Group categories

Difficulty to implement

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: