Heather James pointed me at drupal.org instructions on performing triage in various queues. Naturally, that article focuses on the Views queue, because it is one of the 5 most difficult queues to manage on drupal.org. (To my surprise, GMap ended up being in that list as well.) The things it focuses on are relatively easy tasks, with some suggestions. Additionally, Views has a well defined issue submissions guideline that helps inform users how to submit issues, but also can help reviewers determine if an issue simply needs to be kicked back to the submitter for more information.
The one problem with this is that while anyone can do triage, at this time there's one thing just anyone can't do: assign issues to me to bring them to my attention. Plus, even if people could, if just anyone could do it, I probably would not actually pay much attention to the list, because just anyone could do it, and it wouldn't have a lot of meaning.
However, thanks to recent changes on drupal.org, I can give people a maintainership flag that allows them to maintain the issue queue without actually being a code maintainer. That means I can give this flag freely without the high level of trust needed to have CVS commit access to the project.
To that end, I'd like to form an official Views' Bug Squad. And, if people want, an official Panels/CTools' Bug Squad, though those are much calmer queues and far less in need of gardening than Views.
Bug squad members would:
- Be willing to spend a few hours per week (or per month) going through issues.
- Their primary purpose would be to determine the veracity of issues:
- Does a support request contain enough information?
- Is a support request even answerable?
- Is a bug reproducible?
- Is an issue a duplicate of another issue?
- Is a feature request even valid?
None of these tasks require skill as a developer (though obviously you have to be able to use the software well enough to create reproduction situations) but it can be time consuming. Sometimes you'll end up answering questions. Sometimes you'll just verify the question is legit and kick it up a level.
- Be able/willing to provide summaries.
- Be willing to put up with difficult behavior from a small but vocal population users.
- At higher skill levels, be able to review patches. This is a nice thing to do, but it's less.
- Help out with documentation issues and patches.
- Assign issues to me or dereine when they're verified or simply too difficult for anyone without massive Views' internals knowledge to answer.
- Help evolve the issue submissions guideline for Views, and possibly for all of Drupal.
- Be listed as a maintainer of Views.
- Be able to sign their posts with a spiffy made-up title!
In an ideal world, this team would be enough people donating enough hours to the cause that any one person could rotate in or out and there would still be relatively regular activity doing this. My feeling is that if 7 people sign up for this job, and each person is willing to contribute 4 hours per week, then after a couple of months of this, we'd get the existing 1,000 open issues down to half of that number, the amount of time needed by the team would drop, and those 7 people would have learned a LOT about Views that could benefit them in the future.
It's easiest if people who do this can be on IRC, but that is totally not necessary at all. IRC is nice for having quick chats about issues, but ultimately all of this work can be done directly in the issue queue.
So. Any volunteers?
Comments
Volunteer
Hi Earl,
I would love to help with the views issue queue. It would be a great learning experience for me. I've been programming for 17 years from Cobol to jQuery but have only been using Drupal for about 10 months. I currently am director for an Interactive Agency that has switched all new production from Coldfusion to Drupal. I plan on attending my first Drupalcon in Chicago.
Thanks for the possible consideration.
To be able to add you to the
To be able to add you to the list, I'll need your drupal.org name.
We'll be putting together a nice resource page to make it relatively easy to get started in the coming days.
volunteer
Active drupal user for about 3 years. I've used views alot and try to use it's output in themes rather than bastardizing the output :P
Very proficient in PHP -- not so proficient in the inter-workings of Views but am eager to learn that!
I have ~4 hours per week to give to this task.
regards,
david
...
wow, awesome idea! Didn't think of the potential of that separate project permission!
Although, for me, it doesn't sound completely right to simply assign issues to someone else... but nevertheless, awesome to hear that it at least seems to be a giant step forward for maintaining larger projects like Views :)
Technically speaking, I have the impression we're circling back into a "confirmed" issue property, however, having the small but important difference that only users having the "Maintain issues" project permission are able to assign that property. (And once assigned, it would have to stay; i.e., to not revert it when non-maintainers are updating an issue.)
Assigning to other people
On the other end of the spectrum, this is something I'm *totally* used to doing :) I think it could really help with focusing merlin and dereine's time on issues that require their attention, instead of just staring with abject horror at the number of active issues. ;)
If only certain people have the ability to assign (hey, it's why I have maintainer rights), then, like he said, it means more than everyone being able to do it :) Hopefully in the process, people like me and others get the ability to handle more stuff, and less cross-assignment later :)
I agree, it's not completely
I agree, it's not completely right -- and that's why this system is not going to work for the core Drupal queue, where there isn't an obvious candidate to promote issues to. What we really need for this model to work for Drupal core is exactly what you said; a 'confirmed' status, or some other flag that basically says "This has passed through the level 1 team and now needs someone with more experience/knowledge/whatever" to look at it.
In a traditional support system, one method to accomplish this is that there are actually separate queues, often times, where only the level 1 team has access to create tickets in the level 2 queue. Often the tickets are then linked so that the old ticket also gets updated.
That probably wouldn't work for drupal.org though. A confirmed status would, however, as long as you've got two teams with delineated responsibilities to try and maintain the queues.
The important part, IMO, is that every issue has an exit strategy, so that after a triage team member has looked at it, the ticket goes into a state that makes it no longer an unanswered task. Either by sending it back to the submitter, answering the request, or kicking it up to the next level. If the request is answered, it probably also needs to be assigned to the triage member so that followups can happen.
We're going to write up procedures (and probably refine them as they meet reality) as we build this team. Esmerel is in charge of that.
I'd be willing to donate 3-4
I'd be willing to donate 3-4 hours per week to help out with Views! I've been looking for a good way to help out, and this would be almost perfect. Although, I'm not a developer, I'm proficient at Drupal, and have experience doing QA for a software company.
My Drupal username is mherchel
http://drupal.org/user/118428
Let me know. Thanks!
I'd like to help out, and I
I'd like to help out, and I can do a couple hours a week. At the very least, it can make up for any poorly written bug reports I filed in the past :)
tim.plunkett on d.o
Gladly help you out.
Having worked with you for so long and helping me get to the level of expertise I'm at now I almost feel obligated to help. At the same time I feel I need to spend some time giving back to the community and possibly inspire me to improve my own modules. Count me in to assist in the issue queue. I'm sure I can help others with medium to advanced questions they have in both Panels and Views. CTools I can use some brushing up on, but you can add me to that project as well. I'll block out an hour or so 3 times a week to help close out tickets.
Interested in Helping out
I'd like to help out and can devote 2-3 hours a week in the issue queue. My user profile is http://drupal.org/user/294068
I can help
I wanted to help with documentation of Views anyway, so this will be a good way to see what questions people are generally asking. I'll make myself available 2 hours per week on Fridays. Username is linclark.
I'd be happy to help out in
I'd be happy to help out in such a team, and can devote probably 2-4 hours per week on this. You can find me on d.o as RSchwab.
If there is room for one more
If there is room for one more I'd gladly help out by working in the Views issue queue!
I've been working with Drupal on full time for almost three years now and is actively trying to take more part in the community. Helping out with something as important as your work would be an honor :) I'm a developer at NodeOne where I do module development and laying out sites' architecture.
I'm able to donate 2 or 3 hours a week for work in the issue queue.
I'm dixon_ on drupal.org and on groups.drupal.org. You can also find me on Twitter: @dickolsson.
Count me in
I'd very much like to learn more the guts of views, so count me in for views, ctools, and panels.
Likewise
I would like to help out in anyway possible too.
My d.o username is redpuma drupal.org and on groups.drupal.org
Count me in
Oo - I like this idea a lot. Honestly I'm not sure I can dedicate 4 hours per week, but if 2 is acceptable - please sign me up. :-)
Looking forward to learning a lot more about Views in the process.
The one suggestion I have is to officially include representatives from both the Documentation and Support teams. It is implied they can join of course, but I mean more officially. That way if a bug is "resolved" as something that is "not a views bug", the process then would include review of the issue by these 2 representatives or teams.
What I mean is, a topic which is frequently mis-filed or duplicated, etc -- that *pattern* represents a defect of sorts and users simply are not able to classify what is really a user-documentation/support/Usability/Integration (3rd party modules) issue. Ideally these things become TODO items for user documentation or tutorials.
(Now, it may be that documentation and support folks already mingle through the Views issues for trends, and if so I completely apologize for overlooking this. Just wanted to see if this was an appropriate expansion of the discussion).
I assume there would be a new IRC channel for this effort?
I would love to help with a
I would love to help with a Views Bug Squad as well as with a future Ctools Bug Squad. I've for a few years been in the Views issue queue both posting issues and patches as well as reviewing others issues and patches.
I'm a full time Drupal developer working at Good Old in Sweden. I'm the maintainer and co-maintainer of a couple of modules myself. I would be able to spend a couple of hours each week on the issue queue, maybe not four - but at least two.
I'm voxpelli at Drupal.org, IRC, Twitter, GitHub etc.
Sign Me Up
Hi!
Sign me up to help. I can help out with documentation and whatnot. I am still weaning myself back into PHP code development (been a few years since I wrote code, anyone remember PASCAL?) so I hope to get into some patching later on. My name is my Drupal user account, so, let me know if you need anything else.
Shane
Determine the Most Active Users who are Currently in the Queue
Have you queried the Views Issue queue to see who the most active users are over the last year. You may just find the ideal candidates there. Send them a message and see if they want to get on board. Not everyone checks your blog. We will see the best results from the people who are already doing it, not just the people who say they would be happy to help.
Add new comment