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.