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 think moving to a QA format
I think moving to a QA format would be awesome, but I think using SE / Drupal Answers wouldn't be that great of an approach.
Starting with something like the Commons QA module and integration with Projects and Issues would be way more valuable the extra features on SE.
Some possible benefits of a simple Drupal QA with Project and issue integration:
- Tagging Q's with Projects
- Issue to a Q
- Q to a Issu3
- (converting Forum into a Q)
- link an Answer to a patch in an issue
- Put views into Projects for open and unopened
- Searching issues and QA and documentation all at the same time
- Seeing my QA in my existing Drupal.org Dashboard.
Just a reminder that creating
Just a reminder that creating a package management system on top of Github is probably not trivial. NPM has a large code base, and the jquery plugin site took a year and half to build on top of github and it doesn't even come close to Project*'s functionality.
I find the idea of integrating with GitLab or one of the other gitb based "project management" systems a pretty appealing idea: in that scenario the new tools could point to existing repositories during transition etc. etc.
Dreditor has recently
Dreditor has recently included a "Patchname suggestion" link in the comment form. This makes it easier to get a consistent filename even before uploading.
offtopic, but...
Did you file an issue for this? Because I'm pretty sure you could convince the maintainer to change it. Just a hunch.
Thanks for pitching in
Just wanted to acknowledge greggles and the rest of you for amplifying and refining my original post. A better UX for finding specific modules is what it boils down to. I also like the original notion of having a default sort of popularity - whether it's by "most installed," "most viewed (project node)," or "hottest" (an algorithm that combines most installed/viewed with recency).
Yes, we can find Drupal
Yes, we can find Drupal issues only in drupal.org site by giving site:drupal.org in Google. But it will come only answers from drupal.org and not from whole internet and again we have to search for in whole internet in Google by not giving the word site:drupal.org, otherwise we can not see which answer is good and accurate.
So, every time we have to search in two way for an answer.
When clients and company give pressure to complete the work quickly, then which is the best we depend upon that, and we go to another website which comes first for drupal problems.
I am not lazy, but want more perfection and speed.
However, Greg Boggs and Crell and others, thanks for your suggestion - Can you please write your opinion above in "What are the benefits?" and "What are the risk?" section.
I think it’s absolutely
I think it’s absolutely critical for ‘Drupal’ to have a clear handle on UX Strategy if it is to continue to be successful. Having said that, it’s worth looking at what is meant by ‘UX Strategy’ and also what is meant by ‘Drupal’.
UX Strategy is a way in which the goals of users can be reconciled with the goals of the organization behind the website/app. So right off the bat, we can see that there are many places in which UX Strategy can be applied to ‘Drupal’.
Even with this preliminary breakdown we can see that there can be different UX Strategies for different purposes. Not identifying these channels clearly can make for confusing discussions.
I don’t believe an emphasis on personas is a good place to start a Proper UX Strategy. We need to dig deeper than that and approach the problem by identifying groupings of user intents or task objectives. (I would like to use the term ‘Roles’ to describe this approach but sadly that term is quite buggered up by applying it to describe set of permissions. A given user can constantly change ‘Roles’ but their permissions rarely or never change.)
Certainly this is related strongly to Content Strategy. But UX Strategy also has to provide meaningful guidance to the ‘formal’ or coding aspects that developers deal with on a daily basis. Our current approach leaves developers to solve many critical UX-related problems in isolation and that tends to keep Drupal UX evolution perpetually at the tactical level, generating countless tactical issues.
A UX Strategy is like a skeletal system. It provides deep and critical support for the entire system. Creating a Proper UX Strategy for Drupal is not a small matter. But the alternative is that, in time, Drupal will collapse under its own weight.
As I write this I am wondering if this is the best forum to be discussing these ideas. If I came at this post through the Usability Group context then maybe it is. If I came at it through the 2014 Roadmap Brainstorming context then maybe it’s too much detail for that purpose. But that again underlines the need for a UX Strategy for d.o doesn’t it?
Given all that, I think a good starting action is to identify/create somewhere on d.o. to accommodate discussions and proposals about UX Strategy in all its various dimensions and where we can tackle this sizable problem without being burdened by the endless tactical issues. I believe that if we can get over that hump the tactical issues will eventually begin to diminish.
no, it is different world at SE
I think it is not good idea.
I have bad experience with stackexchange admin folks, as they have oposite meaning of the reason of the question.
Here at Drupal.org, somebody can insert a question.
On stackexchange, you often obtain negative answer of the type "your question is no good for our forum, is very special and have no value for general audience". They are totaly other world.
I think, the StackExchange, as private body, collects fruits of often asked questions, but when you are the first, who run to some special problem (every one of us here at Drupal sometime run there...), you have small chances your question will be published.
Crell brings up many great
Crell brings up many great points about what's lacking in Path Auto. Path Auto is not an end all solution for enterprise websites. Google specifically recommends to avoid -0 -1 -2 URLs. I wonder if Path Auto can be configured to be more useful for Drupal.org and Enterprise websites in general to address the issues that Crell has such as trimming to a certain length and to skipping duplicates.
One of the reasons you have to attach "site:Drupal.org" or "Drupal" to searches is because Drupal.org isn't great at helping Google find it's content. Meanwhile Stack Exchange is good at it, and they come up in almost every Drupal search without the use of "Stack Exchange" in the search.
From Google's SEO Guidelines PDF:
Use words in URLs
URLs with words that are relevant to your site's content and structure are friendlier for visitors navigating your site. Visitors remember them better and might be more willing to link to them.
avoid:
using lengthy URLs with unnecessary parameters and session IDs
choosing generic page names like "page1.html"
using excessive keywords like"baseball-cards-baseball-cards-baseballcards.htm"
Win!
n/t
Possibly, though another
Possibly, though another option would be to choose a different "project management" solution that's better for non-technical projects. Since Github doesn't support "re-projecting" issues either way, there's not much difference.
One other thought I just had
One other thought I just had - this would mean that places like infrastructure, community working group, content working group, etc. would all move their issues to github. Right? Somehow that feels harder to achieve than moving a contrib.
This is one of those ideas
This is one of those ideas that sound great in theory but fall down in practice, especially in a big crowd-sourced site. We already have personas (or roles) in the handbook pages and the tagging is so inconsistently applied by different people that I think it's worse than useless. It's one of the things I'd like to get rid of because of the way it adds cognitive noise without much value.
I like the idea of
I like the idea of 'personas', as we could then add a field like 'audience' to new nodes, allowing users to select an audience. This could give us a new field to add to the search, and/or the site search could be adapted to favor items with an audience targeted at personas the searcher has. This would prevent site builders from getting bombed with code questions when searching for issues.
I know this thread refers to
I know this thread refers to preventing submissions of already existing threads, but on a similar note, that relates directly to the title, I believe that if the submit button is clicked twice in a row with comments (at least), the comment is submitted both times. It may be nice to disable the button using JS after it has been clicked once, thereby preventing duplicate submissions.
I see this fairly often. For
I see this fairly often. For example, on my hosting company's site, whenever I try to post a new ticket, it grabs some of the keywords from my post, searches the site, then returns possible similar searches.
Really, we wouldn't necessarily have to tweak much of anything. We could use the existing search, and do a search on the submitted title to see if anything comes up, and show that. This could all be done with an AJAX interface to speed things up a little.
Drush make relies on release-history metadata - is that staying?
As far as I can tell, drush make (and drush dl) rely almost entirely on the metadata feeds at e.g.
http://updates.drupal.org/release-history/gmap/7.x
We've got a heavily drush-make-oriented workflow, and it would be a considerable loss of convenience to have to move from "projects[views] = 2.x" or whatever to "project[views][download] = git\nproject[views][url] = ..." etc.
For us, then, the essential requirement is for "drush to still work" with the shorthands of simple "drush dl"; the ideal way of fixing that would be not to put a kludge in drush, but to change the way d.o produces those release-history metadata fields persist, so they reference e.g. github package URLs.
As long as those metadata feeds remain, I'll follow the community wherever the download_link XML fields link off to. I have lots of additional opinions either way, but as I'm really happy that d.o continues to at least contemplate and discuss alternative technologies like github, I wouldn't want to contribute to any bikeshedding!
Actually, this will be part
Actually, this will be part of the D7 upgrade, it looks like. :) https://drupal.org/node/44162
I've used Redmine for smaller
I've used Redmine for smaller projects and quite like it as well. It'd be nice to integrate some of the features but I don't know how well it would scale for something as large as d.o. It does have some really nice REST APIs though and if you are sly with your commit messages it will automatically update issue statuses for you. For those who are wondering, Redmine is written in Ruby. :)
Oh and I like how you can respond to an email notification and it automatically posts the response to the issue queue.
Who cares?
Honestly, Drupal.org's Google Juice is already pretty damned good. Googling for an issue and sticking site:drupal.org into the search box tends to give very good results. (Even leaving out the site: filter tends to find drupal.org issues with alarming frequency. :-) ) There's no actual search-engine benefit here.
Additionally, we're talking about well over a million pages. That's a LOT of aliases, with probably dozens of duplicates resulting in -0, -1, and so forth. And the vast majority of those pages are not, in fact, needed for more than a week. It's a wasted effort.
Plus, issues with long titles would then result in pathetically long URLs. Let me be blunt: If your URL is so long that it word-wraps in a standard email client, your URL is too long to be useful. Pathauto with default configuration, sadly, violates that guideline quite regularly. (Yes, there are a lot of sites that violate that guideline. That means they're Doing It Wrong(tm), not that it's not a good guideline.) Just looking at the issues I am following now on Drupal.org, there's probably a dozen on my first page that would result in word-wrapping titles.
I'm -10 on pathauto-on-Drupal.org. We can get 98% of the benefit with 0% of the downsides by just judiciously adding another 20-30 aliases manually to key landing/reference pages. That just requires us to do some rudimentary IA/content strategy to decide what those are. That's way better than abdicating that responsibility to a trivial algorithm and washing our hands of it.
(And yes, I try to tell many clients the same thing. Sometimes they even listen. :-) )