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
Redmine wouldn't be bad,
Except that nobody but me (in the Drupal world) would touch the code with a 10-foot pole. :)
Bugzilla?
My experiences with Bugzilla have been rather uniformly awful. I once tried to install it at a previous employer and couldn't because it required so many system dependencies, eg, it required an LDAP server to even install. That was admittedly 8 years ago and I'm sure it's improved since then, but I've not had a pleasant experience with it.
Project* and Redmine are the issue trackers I hate the least out of the ones I've used. (Redmine wouldn't be bad, actually.)
Yes!
Right now, I Follow probably about 150 issues that are relevant in some way to what I do. My complete Follow list is about 15 pages long. I want to closely follow (and, let's be honest, care about significantly) less than 20 at any given time, although which 20 shifts regularly. Most people don't have the ability to add "Favorite of Dries" to an issue. :-) A difference between "follow to keep an eye on" and "follow because this is where my focus is" would be very helpful.
Throwing flag and bookmark at it is a really easy solution that would suit me fine.
This makes good sense to me.
This makes good sense to me. Thank your for providing details.
I think opening what can be opened will have good cultural value as well as helping with contribution. Replacing all of the restricted assests with GPL licensed assets in the public repository seems like an ideal solution.
I feel that the potential effects on contrib are under stated
While it seems accurate, it feels a bit skewed towards github and a bit of the grass is always greener on the other side syndrome.
The drupal security team spends a lot of time making sure things like this:
http://vel.joomla.org/articles/844-spotting-spam-code-in-malicious-exten...
don't happen
tl;dr;
Drupal spends a lot of time trying to make this happen.
github is nice for developers that are targeting developers, when you are targeting people that are not developers that cannot be expected to test all the code they download, it falls woefully short.
One note is that the linux kernel does not accept patches generated by github as the tools encourage bad patches.
Hi @Bojhan and thanks for
Hi @Bojhan and thanks for taking time to discuss this.
I agree that the idea does lack actionable items and would very much value your input on that.
A couple of things I believe is relatively easy to start with and that should be useful resources quite quickly for the community is:
A set of generic personas
This would be personas based on typical visitor and user roles on drupal.org. It would include, but not limited to:
Then whenever we need to make changes to our sites we will be able to use these personas to better understand what roles will be affected and what they expect to get out from it.
UX review guide
This would be a logical next step after the personas. This guide will be used as early in the change process as possible. Preferable before any changes have been made.
It will show how to select the suitable personas and how to use them to understand for example the workflows different user roles expect and thus be able to identify possible UX problems so they can be addressed.
Of course a complete UX strategy includes a lot more, but these to would be relatively easy to start with as well as implement in our processes.
I updated the title and
I updated the title and description to match the "short story" section because they were different. Now that people have voted on it, though, I'm not sure that was the right thing to do. Maybe the "short story" should be removed?
Anyway, the phabricator idea has more of a substantive suggestion on how to achieve a pull-request-like tool (right?).
@tvenson I do understand the
@tvenson I do understand the confusion. The content working group, focuses primarily on content. It does not focus for example, on community tools like the issue queue. The role of strategic (UX) oversight is the DA, therefor this proposal placed in the 2014 plans seems appropriate.
@webchick Let me know if this is incorrect, but it was my understanding that although the content group has much to do with the overall UX, it does not cover all parts of the experience, which is what this proposal is about.
I am not sure I actually understand the proposal though. It's unclear what steps are involved in creating a strategy, how it will actually benefit d.o. Nothing about this is small impact, both in resources of figuring out and establishing the actual strategy.
Given that from my point of view, the DA/D.O group is still struggling immensely on the tactical part, with little to no UX resources available - having actionable parts to this proposal would increase its success to become part of the roadmap.
It appears that all of the
It appears that all of the people who have reported issues on https://github.com/CMSgov/healthcare.gov are already GitHub users (they all have code associated with their account), so everybody who contributed appears to be a geek (including someone who looks like a Drupaller).
@crell, good points. I
@crell, good points.
I probably painted too rosy a picture of our current issue queue system. I do think that there needs to be some sort "application support system" even if we don't rely on the same system as we do for bug tracking.
Like I said I have hardly any experience with Github except getting code from it.
https://github.com/CMSgov/healthcare.gov doesn't seem to be very good example though of use of the Github issue queue as it seems there only 9 total issues.
I don't think this what I said. I was just pointing out the stated goal of GitHub is as a code sharing site. Like it or not our issue queues are now our default application support system.
If we are going to move our issue queues to Github along with the repo hosting it would seem to make sense to discuss how the issue queues on Github would function for what we currently use our issue queues and if we need to change what we use issue queue for.
If we are going to change what we use issue queues for we should probably figure before hand what will replace their current functions.
Related issues.
Redirect Drupal support forums to Stackexchange Drupal Answers
https://groups.drupal.org/node/312853
Khan Academy does something
Khan Academy does something cool (that's probably lots of work) where it has a "Report an Issue" like on their site which then posts a GH issue with the info there. The issue is posted by a "bot" user so reporters don't need GitHub accounts.
Strange place for it?
Thanks for pointing me to that Angie. But to be honest it makes me quite confused about UX being part of the content WG. UX is about much more than that.
Yes. Which is exactly [part
Yes. Which is exactly [part of] what their charter covers. :)
Well, the worst thing for
Well, the worst thing for URLs and SEO is to have human unfriendly URLs. So, any improvement to URLs would be better for SEO than not improving.
There are a few choices:
How does Drupal handle paths on Module renames? I guess I could test this with a sandbox.
A lot of this could be
A lot of this could be mitigated by the CKEditor Link module. https://drupal.org/project/ckeditor_link
It saves the link in the body as the internal link and then converts it to the url alias when it displays. A little tweaking could get it to convert aliased paths back to the internal path.
I've used it in a couple projects and with D8 including CKEditor by default I think we could get away adding it to all of the textareas on d.o.
I'd be comfortable voting for
I'd be comfortable voting for this if the version were switched from 8 to 9. Given that Drupal.org has been in feature freeze for a year preparing to launch the D7 upgrade, I can't in good consciousness advocate for moving to D8 right now.
Hmmm, not sure..
Issue titles can and do change all the time to further clarify things, or to reflect the state of conversation, or to reflect the current workflow of the issue (e.g. "Needs a change notice" or whatever).
Our options would be:
1) Break the old URLs when this happens, which is bad for SEO.
2) Create new URL aliases to match the new titles, which makes many URLs for the same page, which is also bad for SEO.
Not really. It is about the
Not really. It is about the countless UX problems we have with the whole of *.d.o.
In Symfony2 we prefix titles
In Symfony2 we prefix titles of PRs with [WIP] (work in progress), [POC] (proof of concept), [WCM] (waiting for code commit. Filtering on the prefixes isn't so nicely possible though.
This seems like it would be
This seems like it would be more material for the Drupal.org Content Working Group.