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
The problem is really just
The problem is really just with the main search box in the Drupal.org header (e.g. from the d.o. home page). If you enter "Views" there (without specifying the Modules filter option), the top result is "Views Field View". Clicking the Modules filter at this point doesn't help because the default sort is "relevancy" and there's no "most installed" option. Since we're starting from a search of the full text of the site, a "most installed" option wouldn't make sense as the results include forum posts and documentation etc. However the use of the word "relevancy" in this context can be quite perplexing if the user doesn't understand what they're looking at (and it's fooled me a few times)
As you note, entering the search from module-specific locations (or using the modules filter option in the main search box) does default to Most Installed.
Just because github can make
Just because github can make tarballs doesn't make it a good idea. There are some things we need to do (update xml for usage and security reasons being the biggest, download statistics as a moderate reason) that make tarballs on github a downside to this proposal, IMO.
A dedicated jobs.drupal.org
A dedicated jobs.drupal.org could be a really nice, focused site but his might be a situation where using a third party might be more effective than rolling our own solution. There are a lot of features required to make a jobs board good.
Here's what I did to try to
Here's what I did to try to understand this:
If you end up on https://drupal.org/project/modules/ the default search is by most installed.
What set of steps displays this issue?
Looks like
Looks like https://drupal.org/node/1862196 is fixed in Drupal 7 and I agree with the way that drumm is not fixing bugs in d6 but letting other people do that. I'd say the higher priority than "fix search" is "upgrade to Drupal 7."
+1 for what Greggles said
You hit every mark, my brother...
I'm in complete agreement with you.
- DV
https://drupal.org/project/un
https://drupal.org/project/uniqueness runs (or ran) on ixda.org. I think the results were reasonably good, but you're right that it could become a rabbit hole of algorithm tweaking.
Maybe it would just need to show 5 related results and then a link at the bottom that opened in a new window that showed "more content based on these search keywords"?
This section is so biased
This section is so biased it's hard for me to believe:
The groups.drupal.org/jobs page is the most popular single page on g.d.o. Clearly it is useful for someone ;)
When I think about posting a job into the drupal community I would like to do it based on
We have a system for organizing content and for people to get notifications based on related skill (working groups) and geographic location (regional groups). If we remove jobs from groups we would then have to recreate the taxonomies of skills and regions and we would have to recreate notification systems. What exactly would we have gained?
The proposal lists some goals, but those can be improved without moving them off g.d.o:
I would be very much in favor of fixing things that annoy people about jobs on g.d.o. Based on my experience, the two most annoying things are:
But I'm stumped by the original motivation and proposal in this wiki.
Thanks for the input
Thanks for the input @greggles. However, those links are about Drupal Core. This proposal is about creating a simplified version of that for contrib maintainers.
Tried to clarify the text a
Tried to clarify the text a bit and add a note that anyone who wants to copy the theme could do that already.
This is a great, simple idea. Should be done!
Hence the suggestion of
Hence the suggestion of possibly adopting a larger framework in the Foundation/Bootstrap class. In order to assist with say Bluecheese, you'd have to have inherent knowledge of how that specific theme works. It's true both ways, but on the other side of the fence with a non-Drupal grid system, the knowledge is a lot more documented.
.
I found it somewhat confusing to jump between the comments on the issue and the comments on the pull requests to do code review.
An equivalent of an issue summary would help.
I know I repeat myself when I
I think is would be even more of a problem in the future using github. I think we can assume that github will keep trying to make there issue queue better going forward for the developer's experience. I don't think this is necessarily going to improve the useability for the majority of the current participants in our issue queues.
This discussion coder heavy
I agree that we would alienate a large portion of the community by moving the issue queue. Just looking at this thread it seems that most weighing in are coders but my experience dealing with contrib issue queues is that a lot of people involved in filing issues are not coders.
I think Drupal is a special case in that we are trying to make a tool that allows people to make websites without coding. So we get a lot of non-coders using it and participating in our community. I don't know enough about the general Github community to know if this is common, my guess is not.
If we moved our code and our issue queue you would be demanding that all users of Drupal not just developers create Github accounts if they want to file support requests, feature requests, or bugs. I think this would be a large hurdle and disincentive to most people.
Effectively we would be saying yes you can search for projects, participate in groups.drupal.org discussions but if you want to actually weigh in or get help with a module you have to create this other account for the place we maintain the code.
This is a proposal to make a
This is a proposal to make a guide a standard but it doesn't include the guide.
I don't think this proposal can be considered until the guide is written.
I think there are handbook pages where some of this is written already like https://drupal.org/node/467020 and https://drupal.org/core/release-cycle
I would very much like this,
I would very much like this, but it needs to be done absolutely right and especially for the right reasons.
See https://groups.drupal.org/node/313068#comment-955028 for some of the requirements and benefits this would mean.
Embed image is only a click
Took a look at the github links you provided and my initial reflection is that they are both quite busy with lots of information and at the same time cryptic in the way that there things are as minimal as possible. The link to the commit is just "4e6f06a" for example.
I can understand that developers has no problem with this and that ripping out as much distraction as possible is a benefit.
But that also raises the bar for learning to use this stuff and thus makes it much harder for non developers to get motivation to participate. Especially as we need to understand that these non developers see little benefits of this in their own roles.
I know I repeat myself when I say that this is something that d.o is already much better on, that is including non developers. I strongly feel the risk of this going the wrong direction is high by moving.
On d.o we have the ability to find a good balance about improving the UX, productivity and collaboration for all roles based on our needs. I don't think we will have the same on github.
Once you have attached the image there is a handy [embed] button that does the job for you.
And very busy modules (such
And very busy modules (such as Views when it was in contrib) rely on issue queue maintainers who are not committers to help with issue queue management.
Major benefits after release too
Oh, and lets not forget the benefits after a new Drupal core major is released too. All *.d.o work will continue on it and thus the vast majority of our limited budget will be used to both maintain *.d.o and at the same time the current and recommended Drupal Core!
@webchick: Regarding b and
@webchick:
Regarding b and c:
Yes, budget is of course a big difference between github and d.o. However, I think it is also a matter of motivation.
Currently d.o runs on D6 and it was a massive effort to get it updated to that. The same with the current update to D7. Its not difficult to follow this work and get a feeling for the challenges those working on this are facing.
It is also quite easy to see why its difficult to motivate volunteers to this. Who want to fix D6 stuff when it will stop being supported in a few months? And then updating d.o to D7 when we are busy working on getting D8 ready.
Another problem with this is that it's quite easy to get a feeling that a many see d.o is just a burden that takes massive amount of efforts to drag along instead of the amazing resource and collaboration melting-pot it in reality is.
The arguments in this discussion that moving to github would free us from having to maintain "that stuff" partly stems from that.
Also, lets not underestimate the message we send to potential new users here. If we can't run our own "shit" on what we recommend them to use...
We also know from history that it takes 6-12 months after a new major is X.0 released until enough contrib modules are ported and users see it as becoming useful for building sites with. Also look at how long it took many big D6 based distributions to get D7 versions...
I believe we can rethink and change that scenario.
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.
It would also bring the whole of the community together around common goals, resulting in a lot of great synergy effects too. The project management and work on *.d.o, Drupal core and contribs will be able to co-operate in a whole new way. People will get motivated to volunteer working on d.o as they no longer see it as dragging it along and updating it to yesterdays major, but as a vital part of the development of the new Drupal Core major.
It will also bring in contrib projects into the core development process at a whole new level, especially when it comes to testing API's etc. But also make sure that a number of important, and needed, contrib projects are ported and ready for prime when the new Drupal Core is.
As an added bonus, *.d.o will face fewer needs for tweaking stuff to get it to work as it can be fixed at the source. Just using *.d.o as a test environment will, I'm sure, provide invaluable data and feedback to make each new major much better and ready.
Most important though, it will send a massive message to the market that we take things seriously, that we don't release a new major until we can run our own stuff on it.
Done right, I don't think this will actually delay the release of new majors. Since it will shift teams that now are busy working on D7 stuff to D8 it will actually add resources the community is already spending budget on.
I am also convinced this will at the same time make it much easier to raise funds for important community work too.