Something that we should definitely do early on in this project is get a sense of all the different user journeys we need to accommodate and do a prioritisation exercise around which we want to best support (we'll try to support all of them, but in order for any of them to be good, we need to make priorities).
I would love if you can help me do this by taking a look at this UserVoice list and voting up any existing journeys that describe ways that you currently use the issue queue AND adding other journeys that describe how you come to visit the issue queue (even if you don't do anything once you're there).
http://prairieiniative.uservoice.com/forums/109755-user-journeys-for-the...
I think you'll need to log in to do this - really sorry about that, but as ever, trying to find good tools that match the kinds of things we need to do when we explore projects collaboratively AND trying to make it easier for people who are less comfortable/familiar with GDO to be able to contribute as well.
(I am adding a list of collaboration tools that I think would be very valuable for us in this community to a list of things we might look at tackling down the line... meanwhile, we log in to other people's software.)
thanks as ever for your participation.
Comments
Top User Journeys
reporting back the top five user journeys (based on a pretty limited sample size)
Not sure how you read this, but for me, at least three of these probably artefacts of other parts of Drupal.org not working like they should rather than commentary on the issue queue itself. Also possibly some skew from previous participation here.
leisa reichelt - disambiguity.com
@leisa
Better late than never?
Sorry, but I just had a chance to actually do this. I found a bunch of existing stories I could vote for, but I had a new one to propose:
I'd certainly hope that one gets a lot of votes from existing maintainers... ;)
maintainers are special people...
I'm doing a special research study (albeit a quick and dirty one!) with maintainers as I agree, they have a raft of special needs re: issue queue and are an important use case. So, even if we don't get lots of votes, they'll still get lots of attention. Known issue :)
leisa reichelt - disambiguity.com
@leisa
Yay, thanks :)
That's great to hear. Sorry to generate noise about a known issue. ;) I'm finally trying to make some time to read through and contribute to the content generated in this group since DrupalCon -- it's amazing and encouraging to see how active it is! I figured one of the most important things I could do was to document how to turn ideas from this group into live code on drupal.org (see http://groups.drupal.org/node/141114). However, if there are things in particular you think I should focus on, please don't hesitate to use my contact tab (until we can build a slick "invite" button). ;)
Thanks!
-Derek
turning ideas live = yay!
yes please... in fact I was just thinking before about whether there were ways we could potentially pilot some features, for example the revised issue template so that some people can experiment with it before we release it wholesale... I think helping us get things from idea into reality is an VERY useful thing to focus on :)
leisa reichelt - disambiguity.com
@leisa
Piloting features is [sic] "easy". ;)
There are lots of ways we can pilot features. The most obvious way is using the *.devdrupal.org dev sites. These are little scratch sites that live on a VM. The infra team can automatically spawn new ones or tear them down with the press of a button, so they're fairly "cheap". We could either make a catch-all prairie.redesign.devdrupal.org site, or spin-up separate scratch sites for specific features/proposals.
So, once ideas are to the point that they can be implemented as code changes, we can (should and must) deploy them on these scratch sites as one of the steps to actually pushing them live on d.o itself.
Therefore "all" we need to do is get the ideas implemented and we can try them out. ;) That's obviously one of the primary ways I plan to contribute to this initiative (although hopefully more via mentoring volunteers and reviewing their contributions, not just hacking things out myself all the time).
However, even if we're not yet implementing stuff, if there's anything you'd like my specific input on don't hesitate to ping me. I've got lots of ideas about all this stuff -- I've been thinking about it for years. Over time I'll catch up with the posts and comments and hopefully contribute productively to things still in the design phases, but if you want to throw any pointers my way, I'll definitely prioritize those.
Thanks,
-Derek
+1 the idea of using separate
+1 the idea of using separate sites, especially if it is not an administrative hassle to the infrastructure team. I'm currently working on more than one devdrupal.org site, and it doesn't really create any hardship. Granted, I'm working on two unrelated things, but some of the prairie initiatives, once broken down by function, can be unrelated. The main advantage to using separate sites is it gives the developers the freedom to break, or otherwise destroy, anything they want, without affecting another prairie team's work.
uservoice.com summary - now what?
This issue has been cold for a while. Still, interesting to see that the uservoice poll is pulling together more ideas & votes. I am just updating the total here to compare to the earlier one in 2011 mentioned above.
34 votes - When I can't get something to work, I look for support in the issue queues
Whether it's a configuration issue, a 'glue code' issue (code that makes several module play nicely together), ... I want to know quickly if a similar issue exist, soi if one does, I can comment (or subscribe ;)) to that one instead.
28 votes - When I find a bug in a contrib module, I create an issue in the module's issue queue
I want to quickly select the module's version the report is for, the 'component', etc. Stuff that quikcly helps me to create a good report is great, but it shouldn't get in the way of doing so.
27 votes - When I'm evaluating a module for use in my project
I'm considering to use a contrib module in my Drupal project, and I want to get an idea how the module in question is doing. Are there a lot of issues, how are they being handled by the maintainer(s)/contributors, ... It's a way to decide whether I can 'trust' this module for use in my project.
21 votes - I'm keen to participate in the community but I don't know how to get started contributing
I might be a developer, designer, UXer, writer, product manager, marketing person etc.
17 votes - If I needed to alter a module for a specific purpose, I submit a patch in a new issue.
I think contributing a patch is one of the best ways to give something back to a project maintainer.
16 votes - When I have an idea for a feature for a module, I post an issue
14 votes - I find a problem using Drupal and I'm looking for information or a solution
I'm a site builder or themer with little experience in Drupal development.
13 votes - I want to participate in activities which being coordinated via issue queue
8 votes - As a project maintainer, I want the people using my project to get the help they need…
without waiting for me to find their 'issue' or filling up my world with requests for attention that are not directly related to the job of maintaining or improving the project I've made.
In other words, I don't want to go to the issue queue to see if people have mistakenly filled support requests as project 'issues'. Or feel bad when I get there that support requests have been waiting without answer for days.
7 votes - I coordinate a team of contributors via one or more issue queues.
I'm not sure how often it happens, but the redesign, Git team, and documentation teams all had/have project managers. In addition, within modules that have co-maintainers, often one or more of the developers work to coordinate team members. I also see modules like the Views bug squad, where the team looks to be coordinating via the issue queues.
6 votes - As a project maintainer, I want to get things done...
I want to review patches (or merge commits), read clear bug reports and feature requests, hash out elegant solutions with other people, be able to seamlessly use images and text to describe and understand things, ensure that the right people have seen and if appropriate participated in the discussion, etc.
6 votes - I see spam on Drupal.org
I go to the Webmasters issue queue to report the spammer, so the spam can be removed asap.
3 votes - Learn how a core API was developed/refactored/enhanced
Drupal 7 introduces many new core APIs. Reviewing the issue queue around a specific search term helps understand how new concepts like entities, fields and bundles are implemented and why.
2 votes - I find something on Drupal/D.O that needs fixing but I don't know what module it belongs to
I want to report the problem but being able to report it in the right place could be challenging.
1 vote - As a designer, I upload design ideas for improving drupal
--
OpenConcept | Twitter @mgifford | Drupal Security Guide