UX Case: Love and Hate in The Issue Queue Garden
Click here to watch UX Case: Love and Hate in The Issue Queue Garden.
Update: Based on the insightful comments and questions we’ve received on this proposal, we have decided to switch tracks from ‘UX’ to ‘Community’. The focus is shifted accordingly, away from being about the UX process and more towards the problems we face in the Issue Queue. Yes, we can use ‘UX tools’ to examine those problems but the emphasis would be to shed light on some improved ways we operate and grow as a community.
In that respect we want to emphasize a couple of key objectives of this proposed session:
- We will present a review of the various creative workarounds that the community has spontaneously invented to solve problems of building Drupal and how they are used.
- We will also show how these workarounds might be formalized as designed features to help things move more efficiently.
For reference, here is the original session description:
You may love it or you may hate it, but the fact is that the Issue Queue determines much of the fate of Drupal. Built to report bugs, manage fixes and work on new functionality, it’s a hub of discussions around what’s needed to be done to make Drupal better.
But is it really working for the Drupal community as a whole? Consider the barrier to entry for community members who don’t know how to:
- setting up a Drupal dev/test environment
- apply patches
- understand the technical language
And according to official statistics*, there are around 23,000 developers and almost a million users on drupal.org. That means around 97% of the total Drupal community is locked out of the Walled Issue Queue Garden. [*See mortendk’s DrupalCon Sydney session: http://youtu.be/9lcypjtJRj4 at 13:50]
But don’t despair. There are some simple things we can do to help bridge these two worlds. We’ll present a UX review of the Issue Queue and look at some of the creative workarounds that people have adopted to try make it work a bit better for them. We can learn from this community creativity and amplify it into an organized strategy for integrating everyone’s points of view.
The Issue Queue worked well in its day. But it’s the end of the development trail. Now we’ve grown in size and in our range of community perspectives. Let’s look at ways to get these new inputs into the mix early in the cycle before the gaps turn into an exploding bug list that drains our developers’ time.
Update: We've submitted a proposal for a Core Conversation as a follow up to this session. See "UX Roadmap to the Issue Queue Revolution"
Comments
As someone who teaches students on how to engage the Drupal community, I often see initial excitement in being able to participate in the process followed very quickly by frustration and a sense of being overwhelmed by the issue queue. Anything that we, as a community, can do to lower the barriers of entry should be one of our top priorities. Sessions like this, followed by action, are an obvious path forward.
-mike
I sense a dual purpose in this proposal?! First it sounds like an intro for people to get to know how to interact in the queue. On the other hand it sounds like there would be proposals (and a discussion) for improving the issue queue process(?). Depending on the weight of the second this might be more appropriate as a core conversation.
As for applying patches and making that easy there is simplytest.me making that extremely easy now even integrated with dreditor: http://drupal.org/node/1865822#comment-7080610
Thanks for you comment Gábor. I can certainly understand your concern about the right track for this session. We picked the UX track as we will focus a lot on explaining how we applied UX to review the issue queue to draw our conclusions. And since the issue queue is something developers are very familiar with, we believe that will simply make it easier to identify just how much UX can help improving things for both developers and others as they us it.
In regards to simplytest.me, which is an absolutely amazing resource, I have already been in contact with @patrickd, to involve them in this too. So yes, it will be a major ingredient in both the UX review and proposal.
I think the D.O. issue queue can be improved a lot and stepping back from it and looking for UX ideas from other places could be a good idea. I will probably attend this session.
I think the subject of this is great however I'm not sure a full session is perhaps the best way to present this, in fact funnily enough I think it should be in the issue queues ;) I would certainly attend a core convo or a BoF on this though.
Would you consider an implementation of the D8 "Tour" module for the IQ, in the vein of what's described below?
http://www.ostraining.com/blog/drupal/drupal-8-february/
This is something I'd like to see addressed. I followed the recent CSS standards discussion (http://groups.drupal.org/node/277223) and I think it may have lost some people as the discussion was split between g.d.o, d.o documentation comments and the issue queue.
I'm all in favour of any effort to improve the current situation.
This seems like a much needed discussion. I'm really tired of people miss understanding or miss treating the issue queue, and it's hard to put the blame for it on the newbies.
The issue queue hasn't changed much since I came into the community, and I'm guessing not for quite some time before that either, which means it's audience has significantly changed.
I want to echo Gabor's comments though, that it seems like it belongs in the core track. Awesome ideas presented to a crowd that cares about UX seems much less likely to get implemented on d.o., compared to awesome ideas presented to the main contributers to core.
Thank you everyone for excellent supporting comments and feedback on this session proposal.
A couple of you, understandably, have asked if this proposed session is in the right track. I’d like to clarify that a bit.
In this session we will show how we have used UX principles to: audit the Issue Queue; identify usability obstacles; discovered some of the creative workarounds that users have evolved; and finally how all this knowledge has helped us come up with a list of suggested improvements.
The focus is therefore primarily on the the UX process. And since everyone serious about Drupal will (sooner, not later) end up in the Issue Queue, it serves as a good example to illustrate for this track. The audience familiarity with the Issue Queue will put what we present in a meaningful perspective and thus it will be easy to see how applying UX is a very powerful tool to use here.
As a follow up, we have also submitted a core conversation proposal. That session, if picked, will be focus on presenting our suggested roadmap about how our improvement recommendations can be implemented.
This sounds like an interesting session, but it seems that the use of to d.o. issue queues as an example might be problematic. While it's something that drupal users are familiar with, it makes the session a bit confusing and will likely gather the wrong audience. DrupalCon attendees are likely too familiar with issue queues and will likely attend or avoid this session based on their interest in issue queues instead of UX.
This may be a better session if the example was more generalized. Most web sites do not have issue queues or equivalent functionality, so maybe changing the example to something more universal would make communicating the UX process clearer.
Also, if you'd like to change the focus on the "creative workarounds" and other ways to use the existing issue queues more effectively, I'd be happy to consider the session for the Community Track.
Thanks for your insightful observations on this proposal and the question of attracting the right audience to the session. @tsvenson and I are 100% in agreement that the ‘Issue Queue is the real issue’ here and the UX can certainly take a back seat. That said, yes, this is a community matter and so we’ve changed the track assignment. We’ve also added an update to the description to reflect this shift. We left the original description in there for reference - but hopefully this won’t be too confusing for new readers.
I guess not many people are aware that we fixed most of the problems presented in this session in http://drupal.org/node/44162. These improvements will be available when the d.o migration to D7 is completed.
I tend to disagree that most of the problems are fixed. I have spent some time testing the staging site and from an UX perspective there are still a lot to do. Yes, looking at the improvements one by one, they are improvements, but then testing them and looking at the whole UX and the workflows involved it paints a very different picture.
The parent issue/related issue you point to is an improvement yes, but only a small one from a UX point of view.
I am going to make a follow up post to http://www.tsvenson.com/blog/2013/05/our-drupal-workplace-the-issue-queue where I go over the known changes for the issue queue in the Drupal 7 migration of d.o. Expect it to be posted shortly.
I'm sure you then will see that everything Michael and I talk about in the session still is very relevant.
PS: This is not the fault of the team doing the hard work on the migration, They have done a stellar job from their point of view. The problem is that the product owner doesn't understand UX strategy and why it should have been done before any code was written!