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
I agree with Larry.
I agree with Larry. If we're going to throw "Perfectionist Pat" in as a reason not to move to Github, please note that that blog post was written back when Github was essentially unknown, and was firmly written for a Drupal, patch-using, audience!
However, one thing I think may contribute to more "Perfectionist Pat" syndrome is the fact that there doesn't appear to be a way for a contributor to easily mark their own PR as "I'm just messing about right now, don't bother looking at this quite yet" (aka "needs work"). This does indeed incentivize working in your own little corner because for Github project maintainers, there doesn't seem to be a way to segment "stuff still in progress" vs. "stuff that's ready for you to look at and consider" due to the lack of issue statuses. So once it's proposed as a PR, as opposed to just being a fork, I think there's an underlying assumption there that it's worth bugging someone to look at it.
There are also other forums
There are also other forums that probably don't belong on Drupal.SE, like news and announcements.
There are probably two ways to do a transition:
My second proposal feels like a reasonable alternative since there are some things that aren't suitable for posting on SE. Even though askubuntu exists, there's still the ubuntuforums and other places where people have more generic conversations without worrying about being labeled a "bad question".
I'm always looking out for
I'm always looking out for projects I'm using that need assistance and that are willing to accept comaintainers.
This would improve more than
This would improve more than just SEO. We use "see: drupal.org/node/313598" in code comments all the time. Instead we could be using drupal.org/issue/ajax-inserts-extra-div. This would be very helpful for users both in Google and when reading URLs to know what the URL pertains to before clicking it.
Not a support system
Yes, but that's also rather controversial. I've seen more than one call for the "support request" category to be removed, as it's a distraction. And... it is. Of course, people use it because it's better than the forums, which I've barely touched in 7 years because I find them unusable. (They were weak by forum standards 7 years ago and have not much evolved; and forum software is almost universally bad to begin with.) There's another discussion on here somewhere about dropping those in favor of StackExchange or StackOverflow or something, too, I believe.
I am going to challenge the "d.o issue queues put everyone together!" claim, and the "and that's great!" claim. Both of those have an implicit "GitHub discourages all but the True Coders(tm) and that's bad" claim.
I don't think we can main such claims without hard data, especially on the GitHub side. https://www.healthcare.gov/ is currently hosted on GitHub (https://github.com/CMSgov/healthcare.gov), accepting random updates and edits from the community as Pull Requests. A ton of other Jekyll sites use GitHub/PRs as their CMS.
The "GitHub is just for elite code monkeys" claim doesn't hold water. Meanwhile, we hear complaints about how the d.o issue queues are so bad for "Designers" about once a month (usually accompanied by "because they're built for developers, those mean developers!", which is also BS but I digress). So really, I would hardly say that the d.o issue queues are a paragon of welcoming-ness to all comers either.
So the "GitHub would encourage a white-tower developers-only enclave away from everyone else" claim I don't think has anything to substantiate it.
And even if it did, we should also consider if letting developers focus on code with a better signal to noise ratio and do meta-discussion elsewhere (drupal.org?) wouldn't be a good thing after all. Our general signal to noise ratio has been getting worse over the years.
Brilliant solution! Iceweasel
Brilliant solution!
Iceweasel looks a lot like firefox, but the logo (and maybe a few other things) are different. Let's copy that model.
If the DA insists they won't do this without a lawyer it seems easy to justify the invesment in a trademark lawyer to get more free help on the theme.
I can't think of a single
Perhaps we should do that more often? Less talk, more code?
Cultural
Nothing makes you post a patch now rather than keeping it local or pushing to a Drupal.org sandbox. The tools are no different here, either way. It's all down to how we encourage people to work. There is no affordance on d.o that "makes" people post work early, and there is no affordance on GitHub that "makes" people post work late. This is a complete red herring.
I've got a couple of branches locally on my computer for core now that I never released, because they ended up not being worth posting. Again, nothing changes.
Google is right
We shouldn't get hung up on SEO. As JohnAlbin says, Google is sending traffic to the place where the most relevant answers are.
The added benefit of D.O pushing traffic to SE is this effect is amplified AND SE has other software support forums. There is a good chance that people will discover Drupal as a consequence of being on SE for other reason. Having Drupal support forums on D.O is siloing the content.
Having a canonical forum (at SE) means anyone wishing to help in a support manner gravitates to one place. This has to be good for the project.
An important point would be to have links from D.O which stamp a clear endorsement on this external forum.
Making the documentation a first-class citizen
This is absolutely essential if we want world domination (cough! cough!) I mean "save the universe" (or at least see the Drupal running 10% of websites, like Dries said). This is more urgent now, given the changes in D8.
"Making the documentation a first-class citizen" - this was the title of my idea, until I found this one... :)
I dream of something like this:
http://docs.ckeditor.com/#!/guide/dev_api_changes
I'd pay for it, since I can not help with the doc team (my English is poor). In fact, I am providing my international credit card to guarantee my Drupal Association hat (it must be more than just talk).
@webchick great points
@webchick great points here.
I think this is the biggest drawback of moving the Issue queues to Github which seems would most likely to happen if we moved the Git repos.
Our biggest risk of making this move is that "crossing the boundary" will be become less seamless and fewer people will choose to do so.
If you view Github's about page they clearly state:
and there mission is to
This is a great goal and mission. I haven't used Github enough to know whether they are achieving this but from the feedback I hear from people who are using it extensively they are probably succeeding in their mission.
I think the question we have to ask is Github's mission the same as the mission or goals we have for our Issue queues. I would say that one of goals and part of the success of the Drupal project/community is the seamless boundary mentioned above. Our issue queues also serve as an application support system for those who don't consider themselves coders at all and maybe have never touched a line of php, html or css.
Even though as a huge software project we can hope to have some influence on Github, we should also expect them to continue to strive to tailor their site and issue queues to their own site mission may at times be in conflict with ours.
Social Reward System
I see this as crucial to community motivation. Big plus from me!
I agree with Jaypan, all what
I agree with Jaypan, all what he has written. Yes this is very interesting than if we create a method like giving points to best answer, it will encourage user to answer and moreover if we awarded the best user of the year, it will be overwhelming. This is already in Yahoo Answers. Our Drupal forum will become more helpful.
Bringing the forum module to
Ok, so volunteering is the problem. But drupal already has 28,583 developers. And I think it can be over 33,000 in 2014. Drupal already has modules which are very effective.
If we develop our own forum, it will be our own wheel. We will use it. We can make it better than Stack Exchange. Every wheel company invent their own wheel and try to make better than their competitor.
Why drupal forum is least-loved? Is it because of lack of development or hard to develop?
I completely understand that
I completely understand that this is a complex situation without a quick answer.
In order to protect the trademark of the brand, the elements that make up the “look and feel” have to be definable. An example would be Orange vs Easyjet case a few years back. The exact shade of orange is the cause of the dispute.
If we define what elements make up the brand, we know exactly what parts do not, and I think that will be a large portion of the Bluecheese codebase. You can't say that minor design elements are distinctive enough to be protected.
One solution is creating a Bluecheese base theme that holds all the distinctive branding elements like the logo and the primary color scheme. We can then place the sub-theme in a repo on d.o.
I studied law at university so I know the basic principles but obviously I'm not a practising lawyer so don't take anything I say as legal advice.
Drupal.org used to run on
Drupal.org used to run on betas/release candidates of the latest core release until not all that long ago - either Drupal 6 or Drupal 7 broke that pattern but I don't remember which now.
Getting back to that means aiming to run on a Drupal 9 release candidate (it's already too late for 8.x), and planning for that could start now.
There's two obvious ways to get to Drupal.org on Drupal 9:
starting the upgrade to Drupal 8 immediately after the Drupal 7 upgrade is launched, so it's feasible to upgrade again when Drupal 9 gets to RC.
preparing for a migration from Drupal 7 to Drupal 9 and skipping 8.x altogether.
we could potentially build a
We could also extend our use of git to have pull requests on d.org.
Hard to say, but which would be more work?
Yes! I have several published
Yes! I have several published modules that I myself don't use anymore, which could desperately need some TLC. But good comaintainers are hard to find. :(
I haven't really participated
I haven't really participated in many discussions on here and usually it was just someone asking me to post my insights on a particular topic. So it was more hit and run.
One thing to note: Git was build for Linux and Linux has an onion development principle. ie. you have layers around the core and many people only ever send code to an outer layer from which those changes get to a layer closer to the core.
Hi, can you please move this
Hi, can you please move this to a standalone proposal? No one will see it as a comment on this template. :(