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
I agree with this.
I can't say I really ever have issues with finding things on drupal.org via google.
If I search with drupal as a keyword I get masses of drupal.org results, then if I specifically want more I can click the "More results from drupal.org" link.
I would probably rate searching via google for drupal.org content as fantastic.
I'm not convinced
I'm not convinced this is such a high priority.
There are not many, if any, sites I use regularly that have internal search functionality that is better than just using google.
In my opinion, if you are searching for something on the web, why not use a dedicated search engine, like google.
Google has the benefit of trillions of previous searches and masses of resources to make the more relevant results push to the top.
I do agree that the internal search leaves a lot to be desired, but the solution is not as simple as it seems. To get better results is not just a matter of turning on a search module as is alluded to in the main post.
Drupal.org already uses apache solr for searching and has likely had people spend a fair bit of time setting it up and tweaking it.
We might be able to get some improvements, like increasing the weighting of the module title field higher over the body content, or adding more filter options, but I don't think it's feasible to make enormous improvements and it's a pipe dream to think we can get results better than, or as good as google's.
I agree
I definitely agree.
I really don't think there is that much of an issue with low quality modules anyway.
It's not that common for me to go looking for a new module to do something only to find a module that really looks like it will be good but turns out to be a nightmare.
Usually the modules are good, or there are warning signs, like lack of maintenance and a very small user base.
I know there are broken and duplicate modules out there but if they are useful modules they are often fixed up by someone.
Also, the burden this would put on the reviewers would be insane I would think.
For me personally, after seeing some of the issues in the current review queue, I would probably not bother submitting modules if they had to be reviewed every time and I think a lot of people would be in the same boat. (by no means is this a jab at the reviewers, it's just a very frustrating process.)
While I don't want to end up in the same position as wordpress (either I'm looking wrong or there are a huge amount of bad wordpress plugins), I think less restriction is better than more.
Also Need to Improve Filters
The search feature needs to allow for more extensive filtering - to return results for a specific version of Drupal, for example. Ideally, having the forums completely separate based on version would be best (like the APIs are).
And cleaning out dead, outdated, or downright useless posts would be nice as well. The site is too bloated at this point.
Wow, that's actually an
Wow, that's actually an incredibly simple, useful suggestion we could implement right now.
Would you be able to file an issue suggesting it in the "Drupal.org webmasters" queue and cross-link it here?
I love this idea phiilbar
There is way too much cruft in the DO closet. And it's a bit amazing to hear this from someone who who like to toss out his old shoes but can't. ;-)
I think the next generation DO website should allow reviews and voting on modules. There have been a few that I would nominate for moving to sandbox status, and some that just need to be archived somewhere else.
OTOH, there are sandbox projects that wait a very long time for approval, and many worthwhile efforts that are abandoned because the approval process can be so difficult.
There are more sandbox projects then there are full projects now.
But your idea should be very easy to implement, even with the current D6 site.
Is this necessary?
Drupal.org already has fantastic SEO with Google.
With my own personal website, I have gone to great time and effort to adjust URLs for SEO, and I am finding that Google pays way more attention to the title of the page in the last year than to the URL itself. Be aware that SEO practices are always shifting. URLs matter, but not nearly as much as they once did. Google is continually finding ways to rate the actual content of the page regardless of URL.
As someone mentioned above, the title may change to reflect updates, and this is bad for SEO to have a URL re-named. Many people are searching for up-to-the-minute help, and it takes time for Google to re-assign search ranking to a new URL. My vote would be against this proposal.
Counter perposal
I have an idea. Let's make a "Need Maintainers" project on d.o. with issue queue just like webmaster issue queue.
If a module required a new maintainer then module owner or any other user can create an issue "Need Maintainer for x.y.z module" with little explanation why this project needs maintainer and list benefits if any of becoming maintainer. Interested user can reply to issue and we can fix the issue once we have a new maintainer.
Pros:
Everybody using d.o. is familiar with this process.
It is easy to implement we already have projects like this on d.o.
Any user can subscribe to issue queue or just follow twitter account.
It is a simple work flow nothing complicated in it.
Cons:
"Need Maintainers" project needs maintainers :D
Getting answers
Getting answers is the big thing for new users, else they can't make Drupal work for them. I'd hate to see forums on Drupal go away, but if users are more likely to get answers at SE, then we need at least to direct them there as an option. Many support requests go unanswered in d.o forums.
Highlight maintainer request per module
Usually developers are looking to contribute to modules that they already use. Maybe a better solution would be to highlight the request for a maintainer on module pages or send direct messages to users of the modules that need maintainers.
Something better than IRC?
With all that's new in web technology, couldn't we do something better than IRC?
Also, I wonder if integrating a chat feature into drupal.org would stretch our resources too thin. We have so many issues that need help resolving already, that to add maintenance of a chat feature might overload the available workforce.
However, it would be nice to have something more real time than the forums, but I'm not sure IRC is it.
Great idea!
Yes, I love this idea. Many times I want to retrace and old issue and cannot do it easily without making new search for the topic. Of course, you could use Google Chrome or other browser bookmarking capabilities to do that if you spent the time, but it would be nice to have it in the dashboard.
Similar proposal
This proposal is similar, relating to improved search for modules: https://groups.drupal.org/node/313353
Combine proposals
This proposal could be combined with this one: https://groups.drupal.org/node/313883
Inconsistent
Many people, including myself, have important security-related reasons for not wanting their profile shown. This will lead to the same situation you have at groups.drupal.org where some people have user profile pictures and others don't. Also, while it would be nice to think this doesn't exist, people do tend to judge the quality of input on what they perceive to be stereotypes. I think this proposal would produce an inconsistent visual effect.
Improved search is vital
This is a huge need! Even simple searches return better results on Google than they do on Drupal.org. I think it may be because Drupal.org is so big now that it needs more complexity in search functionality -- the kind that is being continually developed by Google. Kris Vanderwater (EclipseGc) has done some high-level search development for a major online retailer, and I heard a presentation last year he did explaining that. Maybe he could advise.
Helpful vs. non-helpful
This sounds great to me. Hopefully it would encourage more people to get involved in reviewing and speed up the time to delivery on solutions. My question is about your term "helpful" in listing the reviews on the user profile page. How could it be known if the review was helpful or not? Maybe just plain "reviews" would suffice.
Trying to file an upstream
Trying to file an upstream issue against symfony with Daniel. I'm further against github now.
The connection between pull requests and a specific issue is not tight and there is not real coherent view of the history and activity.
Also, my comments on the PR were erased since Daniel force-pushed changes to those lines. As much as I'd sometimes like to erase a review's comments, I don't think that's in line with our community values.
@User AdvocateI see where
@User Advocate
I see where you coming from. Yes, if we where to look at personas from a purely UX design and strategy perspective, then I agree with you.
However, if we also look at personas as an educational tool for the community I believe it could provide a game changer.
After all, there are quit a few of us within the community that have been barking the UX mantra for many years now. Yes, we have had some progress and a few wins. It has helped Drupal to become more user friendly too. But, looking realistic, UX is still not taken seriously enough or applied early enough in our processes.
Also, UX is still kinda treated with some suspicions by many, even that that our ideas slow down getting things done. It is a complex beast and it takes time to really understand it, what it can do and why it is important to spend resources on it.
Exactly, and this is where I believe that the persona tool very well could be the one to help us start making an important change here.
A set of well defined role oriented personas would include both a general role description and good definitions of their task objectives. A guide document can then describe how to apply them and also how to discover and extend them for new drupal.org features as well as Drupal Core and contrib.
It could help us begin to bring down the wall that over the years have been erected and now effectively separates drupal.org and Drupal. A wall that has made them into two separate and quite unrelated entities.
At the end of the day, drupal.org is built on Drupal - It is depended on Drupal to function.
All the challenges we have maintaining and running drupal.org stems from what features Drupal provides. In that aspect drupal.org is no different from any other site it is used on.
But we are in a unique position. We maintain both drupal.org and Drupal. In many cases it is the same people even. Still we treat them differently. Another aspect that is unique and separates us, from other sites, is that the community goals and objectives are all focused on improving and spreading the use of Drupal.
So, personas done right right can very well become the tool to help us bring down the wall. Allow us to instead build bridges for creating awareness, understanding and education about our UX needs.
Its not "the" solution, but it can be the start towards it.
How go find out about the roles then?
Could you expand on this a bit? How to dig deeper? What kind of research and analysis is needed? Wouldn't a pragmatic set of personas be a good place to start and find out about a higher-level grouping of tasks?