exploring the problem space - where are the pain points?

Let's start at the very beginning.... Here we make a list of the what pains us about inereacting with each other on Drupal.org - in the issue queue and beyond. What are the opportunities to do better?
Add your thoughts here.

so, I'm sitting in the Git session at Drupalcon and they've just shown an awful Information Architecture problem that I can help them solve... there needs to be a dead easy way for me to say 'I can help with that'.

I agree. But also would like to see a way to distinguish between a) someone who wants to volunteer to help (but would benefit or needs guidance) and b) someone who wants to help because they are a domain expert. My concern would be doing it in a way that doesn't in itself introduce hurdles

It's important to note that the fields that are on profiles right now focus mostly on "What have I done for and with the community?". I would be wary of any changes that would turn these profiles into a way for people to promote themselves and their services.

You should be able to add new issue tags w/o adding a comment, preferably inline.

You should be able to follow/subscribe to tags.

Tag pages should have the option for creating a tag description and list somewhere prominently in the IA that it is a tag page.

Tag pages should include a lot of meta-data about tags (See quora topic page for an example - http://www.quora.com/Drupal)
* How many issues use this tag.
* How many people are following it.
* How many projects use this tag (and how many issues within each tag).
* Who are the most prominent people within issues tracked by (ranked by # of comments, # of commits, # of issues they follow, # of votes on their comments within tagged issues, etc). Highly useful for finding domain experts.

We've talked a lot about how to organize larger initiatives + help people working on related issues get coordinated. Improving the tagging systems would help out a lot on these two problems.

It'd be really nice to see as a project maintainer who uses or is helping out with your module. It'd be nice if users could flag a module as something they use + it'd be nice to see statistics about who is posting issues + who is committing/contributing code.

I know it is a bit painful (actually really painful for some) at times. Nevertheless, it is so awesome people are actually learning how to think about opportunities together, and to work together to solve challenges.
Sorry if I've taken anyone off issues at hand!
Praise God!

One of the ideas that came up when I was listening to the Prairie talk in Chicago was that there could really be more mechanisms to lead people to close issues. Often folks don't know what else can or should be done or how their skill set can plug into an issue that they are concerned about and want to see addressed.

I'd like to involve the contextual information about what skills/experience a user likely has and combine that with what is typically needed to close off an issue. If someone's contributed documentation and an issue is waiting to have docs added before it is marked RTBC, there should be a big encouragement for that individual to take the next step and evaluate the docs.

If we know that an issue needs UX or Javascript review, then why not highlight that when folks with that experience view the issue.

Now the core & contrib issues are going to vary, but ultimately it would be great to have the new issue queue help identify missing steps and things that generically can be added.

In lower traffic queues especially this is a huge problem. Would definitely be useful to help show (like with the core issues block) how many are needing review for each queue. It might help direct people into helping actually close half-finished issues and get them out of the queue.

Personally it took me a long long time before I dared to start change the status on issues. I think that for us who are less experienced in coding and/or how Drupal works, this is a threshold that takes quite some time to get over. It only the last few month I have felt more comfortable to use statuses such as "reviewed & tested by the community", fixed and so on. Before that, I would only post a comment saying that a patch worked for me and then hoping someone with more experience would confirm and change the status.

Regarding marking with RTBC I believe it will be an even bigger mystery for less skilled coders. In most cases we simply don't have the knowledge needed regarding what is needed before that. I would only do it if I see someone I trust saying something like "All that is needed before RTBC is..." and I can test and verify that it is done.

The only way this can improve so that more of us can get more involved is if the available information for the issue is easier for us to grasp. I think there are ways this can be done without making it into an annoyance for those of you that are really core.

One such improvement could be to use dynamic checklists. For patches it should be pretty easy to create a generic checklist covering what needs to be done, tested and reviewed before it can be RTBC. At the same time it would function as a guide for patch contributors about what is expected for their patch to be accepted quicker.

Maybe it would also be worth looking into if a bigger restructure of how individual issues are structured. Issues with tons of comments (excluding the subscribe/+1 "spam" comments assuming that will be fixed soon) can be hard to get a grip on if your not experienced enough, especially if there are many patches in there.

Making it possible to edit the OP would be a big improvement. Then that can be used to link to the important comments, as well as short info on what is left to do before it can be marked fixed.

Attached to the OP could also be dependencies on other issues, both those that needs to be fixed before the issue can be fixed and issues that depends on it.

Breaking it up in tabs where you have one tab for general discussion and then one for patches where old patches can be hidden would also help to improve things. The patch tab would then only show the current patch(es) with individual checklist and and have its own comments. When a new patch is replacing it, then the old and its comments could be hidden.

If patches also are handled separately from other attachments, then it would be possible to improve the "View pending patches" search shortcut as well. Especially the RTBC list would be a great help for users to quickly for fixes to issues they have before they are committed and released.

I guess what I am trying to say is that if a lot of what is now spread out in comments are moved to be attached to the OP, then it would be very quick to get an overview of the status of the issue without having to scroll up and down searching for pieces of info.

Not only would this make it so much easier for less experience users to find information and be more involved, it would most likely save a lot of time for maintainers and developers as well.

Lastly, is there some universal rule that issue trackers still has to work with Mosaic 1.0 and look so boring? Isn't it time they too make use of more modern and dynamic UI's?

For the past 5 year I've been wanting to contribute to the development, but lack of time makes me too disconnect with when things will happen. Now code-names help a lot to rally people together, but you have to be on the information flow 24/7 to recognize them. I've been lucky to go to the right session in Copenhagen to know about the code-name "Butler". However, in Chicago I've misted the code-name "Prairie" only because I was 20 min later in the session !! Can't imagine how many other things I'm missing out. I've got no clue how to solve this, but there should be way to broadcast code-names.

I actually get to this post as Roy Scholten asked me to do so in my own blogs about using VoIP for virtual sprints. The blog is about the development happening by being on IRC, again a case of needing to be 24/7 on the flow. When I was trying it, I was reading most of the time and hardly working any more ! From online gaming I have experienced VoIP walkie-talkie like conversation, which allows you to lissen in on such conversations while reading other stuff. I think this would be a way to get easier on top of things.

My main problem is that I'm unable to contribute as there are too many things and all move lightning fast. I would like to see more specialized notifications so that it becomes easer to cherry pick instead of following all the treads. This could be useful for things like e.g. planet-Drupal, lately filtering that has become a time consuming task. Maybe we need a Drupal ontology that allows us to regulate information by use more meaningful tags.

I agree, this is a Big Issue. As someone who spends little time in IRC these days, I really feel this a lot.
(and as someone who's trying to push a Big Initiative/Code Name, it's equally frustrating to know that most people won't find out about this until we're way down the line with it).

Here's a question - I wonder how broad/narrow our tags/taxonomy would need to be.
For me, for example, I could just follow UX or Usability or whichever one we decide on and that would be a good enough 'ping' for me... but what about the rest of you?

What kind of tags would you want to follow? how broad/specific would they need to be do you think?

Drupal.org: Moving from concept to development to deployment: This process is currently a bit of a mystery and has some hard dependencies on some extremely busy people, which makes it more difficult than it should be to improve d.o (though post-redesign it's vastly improved). I'm planning on spending a good chunk of time between now and DrupalCon London to help document and smooth this process out so that someone who has incentive to improve our tools has a roadmap about how to do it. I'll be doing this over in the So you want to make Drupal.org awesome? guide.

Where's this issue at? As a consensus-driven community, often times particularly gnarly decisions can involve dozens or even hundreds of participants. Probably the biggest turn-off to people doing core development is trying to waltz into a frenzied, heated issue and try and deduce things like:
a) What is the actual problem that we're trying to solve here?
b) What is/are the proposed solution(s) and their pros/cons?
c) What are the contentious issues that need hashing through (if any)?
d) What is left to do on the issue before we can mark it RTBC? (and can I help?)

I'm a core maintainer, so I get to cheat and just ping people on IRC if I only have 15 mins to understand an issue. Other people don't have this luxury, so we need a way to get "outsiders" (in the loosest sense of the term) up to speed on the state of a discussion and what the remaining TODOs are. Various methods for this have been proposed, including a wiki-style "issue summary" that everyone can edit, or the ability to "flag" one particular comment as being a useful summary of the state of things.

Transparency and centralization/aggregation of fragmented activity: (This is similar, but is not the same, as the above point.) Something I'm extremely concerned about with Dries's proposal to spin off "sandboxes" to work on various "sub" initiatives is completely fragmenting the core development process, and particularly the core review process. There were a few initiatives in D7 (Bartik, Field API, etc.) who outgrew Drupal.org's collaboration tools and ended up happening over on Launchpad or GitHub or other places like that. This made it literally impossible for me as a patch reviewer (since that's all a core maintainer really is is a souped-up patch reviewer) to understand:
a) Who's working on this initiative?
b) What does the end goal look like?
c) What's its current status?
d) Is it active or is it completely dormant?
e) Most importantly, if people come up to me and ask where they can help, what is the answer to that question?

The Git migration helps to some extent, as it at least keeps some of this fragmentation on our own infrastructure. But especially if we start talking about tailoring separate tools for brainstorming/design and separate tools for documentation and separate tools for developers, providing a unified interface for patch reviewers to figure out where to find all of the underlying information is crucial. Without that, we lack transparency into the development process which is very important to understanding the impact of a change.

Sub-standard tools for "meta" discussions/brainstorming: Issue queues are very good as collections for actionable tasks that have code applied to them. You get a clear workflow state (needs review vs. needs work vs. fixed), patches get tested by testbot, etc. However, they're absolute crap when you deliberately want to keep discussions out of implementation because you're trying to have a higher-level architecture discussion about them, or you're trying to play Photoshop ping-pong, or whatever. We end up defaulting to groups.drupal.org for this, mostly because you can't physically upload patches here, not necessarily because g.d.o provides a good framework for that. ;P

I don't have any great ideas about this, but I know others have chimed in elsewhere. Off the cuff, stuff like auto-inserting image thumbnails so design/UX folks don't have to learn HTML, adding the ability to create "spec" documents in wiki form or something so that it's clear what's been decided on vs. what's still in discussion, etc.

No way to get out important targeted announcements. Most developers have long stopped looking at the d.o front page. Most have also unsubscribed from the development list, which has since become Yet Another Fracking Support List. We've abandoned the forums. Even Drupal Planet is in dire straits, since on some days it's more marketing and tutorials than it is solid API information. As a leader of various development-focused initiatives, it was extremely difficult to get out word about, say, the Git migration and various late-in-the-game D7 API changes. I imagine other folks (D4D, UX, etc.) have similar problems.

We need a section on Drupal.org similar to the "Drupal Digest" site that was around awhile back, with carefully curated and tagged posts of incredibly relevant information to sift out of the noise to incredibly busy people.

I'm sure there are many more, but that's hopefully good as a start. :)

We need a section on Drupal.org similar to the "Drupal Digest" site that was around awhile back, with carefully curated and tagged posts of incredibly relevant information to sift out of the noise to incredibly busy people.

I want that Drupal app! Can you do this with core only? I've actually tried to built something like this the other day. I was thinking that I could use aggregator to follow feeds, then organize selected items from that feed as pages in book module or something but that didn't work out (I didn't try very hard though :)

Regardless, something like this would be great to have. When searching for a fix to your Drupal problem of the day, you will often find the answer in some blog post/tutorial, not the handbooks. Having the useful posts collected somewhere would be a great asset to have on d.o.

Its not the first time I have tried to get more involved in the community, but in the end given up because nothing happens. This is probably due to that I don't have the personal network needed to get thing happening. My involvement in the community is 100% through the internet, I haven't had the opportunity, yet, to go to any Drupal events to meet any of you person to person, which for me seems to be the only way to get a foot in and get something done.

As a consensus-driven community, often times particularly gnarly decisions can involve dozens or even hundreds of participants.

For Drupal 8 Dries is talking about "initiative owners". In my opinion this is needed throughout the whole community. From what I understand those that are Drupal Webmasters pretty much pick and chose from a list of things (the issue queue included) to do. Few have personal tasks they are looking after and are responsible for. This works for issues that quickly can be fixed or bigger things they have a personal passion for. Everything else that is not so fun and will require a lot of work will simply be put on ice.

I am not picking on anyone here, I know that everyone does a fantastic job and that they can't do everything, especially since it is on a volunteering basis in most cases.

I am sure that there are many more like myself that would love to get more involved, but gives up sooner than me because we are not really feeling that our help really is welcomed. I strongly suspect that not being an experienced coder is not to my benefit here as well. However, everything doesn't require coding skills. Administrating Planet Drupal, and many other things, certainly doesn't.

One of the first things I tell prospective clients is that my motto is to put them in control of the content on their new site. When I have explained that making updates to content will be quicker and less expensive for them, most are smiling because they realise it is to their benefit. Its about using the right skills at the right place.

Same on d.o. People like myself are able to greatly offload a lot of work, such as administrating Planet Drupal, from the small number of people now doing the lion share of work. We would be happy to do that because it is on our skill level and we know it would benefit the community greatly. As we gain more experience we can help with more.

The Drupal community simply is to big and growing to fast for the structure and organisation it currently has. It worked fine 5-6 years ago, but not any more.

If nothing is done about this, then the only outcome is that Drupal will lose momentum and new users will go elsewhere.

It needs to be much easier to find out how to propose changes, who to talk to and so on. Then decisions needs to be taken quicker so things actually happen before the enthusiasm runs out.

Sorry if I got a bit off-topic, but I think it is important that new users that want to help feel welcomed and that their contributions efforts are worth something no matter what it is.

"This is probably due to that I don't have the personal network needed to get thing happening." -- don't give up now, you've been around enough to start getting on peoples' radars. The more you help, the more this will happen. :) Sure meeting in person is great, but the work that happens the other 300+ days of the year online is very important.

It's really true that the lack of delegation from more experienced/involved members can lead to loss of momentum in various areas (because we're too busy to keep up on everything, even though taking the time to delegate would help that!) But it's a chicken and egg thing. Set up the infrastructure to allow more help before there are helpers OR wait till there are helpers stepping up before setting up the infrastructure.

My point: It's good to keep being reminded there are people willing to help with things that more experienced/involved members might think is gruntwork that nobody else wants to do! Then we just need to take the time to change the process (which granted can be a hurdle in itself) - it's going to become more and more necessary as we grow.

I've been using Drupal for a couple of years now and one thing that I've always had trouble with is contributing as a Graphic Designer.

There are a few initiatives going that are working towards distro's for designers to use to learn Drupal and act as a way of getting more designers using Drupal. This is great for new designers coming into Drupal and it's nice to see attention being given to that particular subject but the next stage on from this is where I see an open issue for people like myself and for the designers that are currently using Drupal and have an intermediate or higher level of theming.

A solution to this problem would be to give designers a way to contribute back by a means of uploading a range of graphics to d.o that would be available to the community and would go towards helping a range of new developers and themers by removing the intial design phase for them so they can concentrate on getting into the code with less design issues to think about. This could be done by adding another category to sit alongside Modules and Themes with a few sub categories for easier navigation.

So what would designers contribute? A few things i've thought about and have ready to contribute are:

Icon packs, (yoroy has started a similar idea with his Protocons pack)

Sliced PSD designs, I feel these would help new themers and would also improve the designer/themer collaborative process in Drupal and could spark more interest for designers and could even see a rise in contrib themes.

Graphic packs, these would essentially be design elements that could be incorporated into an existing site but would not be an entire theme/layout.

Marketing media, Brochure templates would be a way for Graphic Designers to help with leaflets for things like Drupalcamps and other Drupal get-togethers.

For those that like to focus on design this could really open up a lot of possibilities.

I'm trying to help work through an issue queue right now narrowing down the number of issues. I know there are duplicates there because I've seen them, but I have no good way to keep track. I've resorted to keeping google docs and pasting in links to possible duplicates to go back to and review.

Creating the ability to 'flag as possible duplicate' would probably be simplest path forward since it involves human intelligence.

I'd love to see a block like what we have on project pages now that lists related modules listing possibly related issues.

While I'm dreaming some support software I've seen does live suggestions of pages that might answer your question before you create a new one, wouldn't that be awesome?

Now that I think about it why limit this just to issues? This could be really useful for forum posts as well.

That block is very reliable in my experience, at least for blog/news-y content, I reckon it could work for issues as well - at least, you can use user ids, tags, comment body and weight them so it ought to be doable.

Another thing I'd really like in terms of duplicates would be the ability to add an actual node reference between the duplicate issues when marking it as such - currently the only way to do this is manually link between the two issues in comment bodies, and I have a bad habit of marking issues as duplicates of themselves when trying to do this with 15 tabs open. We'd then be able to show the actual duplicate issues (and other things like dependencies) somewhere obvious instead of buried in the comments.

It'd be nice especially for contrib projects if there was a place for meta-conversations around that. Those conversations sort of happen in issues but it's an awkward fit. There's a lot of projects where I'd like to hear about new announcements and participate in high-level design discussions but where I don't want to subscribe to get emails about every issue. Basically what would be nice is if there was a mailinglist/group associated with each contrib project. I think this idea was thrown around during the d.o. redesign discussions. Fun stuff could be done here like sending out an email to subscribers on each new release, etc.

...is finding where to start. As much as people say 'jump in the issue queue' that's scary and unrealistic. It almost has to be a caring mentoring process, and I'm not sure how that can fall any responsibility on d.org itself rather than the community. This also requires that they know how to get started and where to ask questions.

I (still) think the single best thing we could do is to just add some simple node-referencing and a few additional status fields to the issues. I posted this to one of the "fix the issue queue" type issues but will post again, the most useful thing for managing lots of issues (c/o Unfuddle in this case):

I agree that being able to see related issues is really important, I'd like to think we might be able to improve on this UI but at the same time, don't want to hold up progress if someone can jump on this and make a rapid improvement.

so, from my perspective - if this can be a quick fix, let's get to it. But don't be surprised if a little further down the track we're taking another look at this :)

(assuming that you haven't already jumped on this... couldn't find anything to indicate you had but I am horrible at finding issues...)

Finding the right conversation/issue queue is one of my main pain points. I believe it's related to the issue Webchick posted above:

No way to get out important targeted announcements. Most developers have long stopped looking at the d.o front page. Most have also unsubscribed from the development list, which has since become Yet Another Fracking Support List. We've abandoned the forums. Even Drupal Planet is in dire straits, since on some days it's more marketing and tutorials than it is solid API information. As a leader of various development-focused initiatives, it was extremely difficult to get out word about, say, the Git migration and various late-in-the-game D7 API changes. I imagine other folks (D4D, UX, etc.) have similar problems.

Not all issues are created equal on d.o, and without a really useful overview of issues and - perhaps more importantly - subjects under discussion, I find it hard to figure out where to use my time and energy.

Without pretty intimate knowledge of the Drupal community it's also difficult to know who has the power to issues from discussion to action and deployment.

With Core and contrib development it's easier since you have official project maintainers. With design issues it's a lot harder to figure out who has the power to take action.

This last part isn't about the issue queue, but Drupal organisation. On almost any project we do commercially we have a lead dev, a lead designer and a project manager. On drupal core you have a lead dev (yeaj!) but no formal organisation on the design part (that I was able to find).

More general challenges. I will probably be repeating previous comments a bit but we seem to be zooming in on handling the process of managing workflow within a single issue. I think much of the challenges are in the engagement before even finding a relevant issue you might want to contribute in.

Figuring out what kinds of contributions you can do: code, reviews, docs, design, events…

Finding small, novice tasks that fit your skills.

Finding out who are experts, leaders, mentors in the area you want to contribute in.

Getting an idea how the small bits fit into a larger initiative.

I'm thinking the user profile page and the personal dashboard could do a lot in pointing out reasonable next steps.

Think back to your own newbie days. What did you do on drupal.org before bumping into an issue queue at all? Or was an actual issue your first contact? Then, how did you branch out from there?

I started by posting bug reports and howtos on the forums, at that point (2005/6) people like Heine, Peter Wolanin and webchick were all posting on the forums as well, and they'd link to issues if they were related to what I was on about and the functionality didn't exist as a module. This is when planning, tasks and feature requests actually used to happen on the development list and in the forums, and there were only 30,000 users registered on Drupal.org so traffic was low enough that people could more or less keep track of what was happening. Then I started finding issues that were bothering me (forums, comments, performance, not much changes does it...), they weren't moving very quickly, so I'd do basic things like test the patches or re-roll them when they were stale to try to keep them moving.

Five years later I no longer post on the forums, nor read the development list, and didn't read Planet for about a year until the dashboard widget showed up in the redesign because the proportion of posts I was interesting dropped to near zero - many people are the same by this point. For about a year I used to check groups regularly, now I more or less only end up here via irc or twitter. Within the past 18 months I can no longer even pretend to keep track of the core issue queue, it used to be somewhat possible before.

The biggest danger of this situation, for me at least, is that we have these places (development list, forums) which other projects do too - but for those projects, they actually discuss development of the project on their development lists instead of leaving it for years as a support desert. Look at the number of forums in the 'deprecated' forum, that have posts within the past couple of weeks for example - http://drupal.org/forum/19. People are going to arrive at these places, take them at face value, and either get stuck there for a while (or permanently stranded), or immediately give up and go to another project.

I feel like we keep stringing these old legacy places along because people still use them, even if they're completely counter-productive now. The 'closing the drupal support gap' core conversation by hedgemadge, and other discussions around actually shutting down the development list, closing up half the forums etc. would be great to see some of this happen. We can't shut places down without replacements, but equally we can't just keep adding more and more layers of places on top of things that are already dead. i.e. - if we have support.drupal.org or whatever it's going to be called, then we should kill off this monstrosity<a/>.

I'm just a newbie to the whole Drupal thing (about 6 or so months and have never attended a DrupalCon). While I have been pretty happy working with Drupal (with the code and modules that let you get up and running so quickly), I haven't really had such a warm fuzzy feeling within Drupal.org. It feels a bit like a disjointed bureaucracy, cold and anonymous at times.

The main issue for me is that I don't follow discussions on IRC and find it hard to know where day to day development is happing with Drupal core, is there a major push on issues in a specific area, is that an area I care about? There have been a number of times when a new core feature has been written and almost finished when a respected member of the community will come along and say something like: "Wish I'd known about this effort before, because X,Y and Z are massive problems because of the path development went down". It seems like keeping people informed about what is going on in the issue queue and activity around that would be useful. I was at the session in Chicago and the suggestion that we might actually want to look at something like Facebook's newsfeed struck a chord with me. I think Facebook might actually have it easier than we do, because I told it what I'm interested in and so it can work out what I think is important to me.
But at a basic level, this might be something like: a "Similar issues to the one's you've participated in the past" section, and maybe a "What's being worked on now" listing (this one should probably not list specific issues, but pull out aggregated data, i.e. there is a major push on the 'theme system').

This is where implementing something like Quora's feature of following topics would be hugely valuable. If you could follow certain tags and then have relevant items related to that tag be pushed into your news feed, that would go a long ways towards solving this issue.

I think all some good points. I have been set back often times in committing code, not due to lack of experience or ability, but the nit picking that sometimes goes on as far as Drupal.Org coding conventions. (IE line length, tabs v Spaces, How comments should be written, etc). I think this is probably one of the biggest issues and there is really nothing much you can do about it because a maintainer will have their preferences. I have seen modules that follow the coding conventions to a t, and I have seen others that are just ignoring them completely. This wide range of attitudes makes it hard to know how to approach anything sometimes.

The other thing that has really drove me away from committing directly on D.O is the witch hunt for any sort of functionality duplication, even if your doing the same essential functions in different structural ways. This can be a bit of a pain and has caused me to close a module before because of it. I want to contribute, but i dont want to get whined at when i do if on the surface my module looks similar to another one.

I think all some good points. I have been set back often times in committing code, not due to lack of experience or ability, but the nit picking that sometimes goes on as far as Drupal.Org coding conventions. (IE line length, tabs v Spaces, How comments should be written, etc). I think this is probably one of the biggest issues and there is really nothing much you can do about it because a maintainer will have their preferences. I have seen modules that follow the coding conventions to a t, and I have seen others that are just ignoring them completely. This wide range of attitudes makes it hard to know how to approach anything sometimes.

The other thing that has really drove me away from committing directly on D.O is the witch hunt for any sort of functionality duplication, even if your doing the same essential functions in different structural ways. This can be a bit of a pain and has caused me to close a module before because of it. I want to contribute, but i dont want to get whined at when i do if on the surface my module looks similar to another one.

ok, so I wanted to just put together a quick summary of the key points that I'm hearing in this thread so far and that I think we need to look at addressing. In no particular order:

Discovering how to get involved, feeling more confident:
- It needs to be much easier to find out how to propose changes, who to talk to and so on. Then decisions needs to be taken quicker so things actually happen before the enthusiasm runs out.
- develop a network of people around you, start to get to know who's who
- mentoring?

Finding Issues
- I want to be able to easily find issues that I'm interested in, might want to know about, might be able to contribute to.
- need to be able to add a tag without disrupting the flow
- a way to broadcast major initiatives, things that everyone should know about.
- give designers/documenters/non-coders an easier 'in' to contribute

may be achieved partly through
Tag Pages:
- a page that aggregates information about a tag used in the issue queue a la Quora, ability to follow tags for notification/activity feeds.

Issue Summary:
- who has contributed and how? commented, voted, following, written/reviewed code/designs etc. An easy way to see who is involved and who needs to be (invite/ping) and to ping a group?
- ability to update the OP or a way to show what the current status is, where we're at
a) What is the actual problem that we're trying to solve here? b) What is/are the proposed solution(s) and their pros/cons? c) What are the contentious issues that need hashing through (if any)? d) What is left to do on the issue before we can mark it RTBC? (and can I help?)
implementation ideas including a wiki-style "issue summary" that everyone can edit, or the ability to "flag" one particular comment as being a useful summary of the state of things.
- showing related issues for context

Separating Ideas from Commentary
- need a way to separate out ideas and next steps from discussions around each of these
- need a way to agree without disrupting flow (voting, +1ing)
- split/tab out chat from patches (and UI presumably)

Closing Issues:
- what's the next step? what's needed? how can you help?
- marking RTBC is scary - how can we make it less so? (perhaps participatory? - I would only do it if I see someone I trust saying something like "All that is needed before RTBC is..." and I can test and verify that it is done.), checklist for RTBC?

I think that we also need to much more consider the need of new users and especially those that simply are looking for a tool to build a site with. Especially I think we need to find the best way to separate what is user and what is developer information.

For the issue queue it might be worth looking into how for example the support and feature request categories can be separated from bug reports and tasks in the UI for example.

Oh man. Just trying to do a sufficient review of this thread as it stands required addition of a todo item on my list for the day.

For me, that's the problem with discussions on d.o/g.d.o and why I'm not as effective in issue queues as I might be. I don't know what the concrete changes that I'd like to see are, but I do have some pain points.

I'm busy. I do client work, I do contrib work in my own silo, and then there is this whole universe of things happening that I might like to be involved in. However, figuring out if I'd like to be involved/what I can do/getting up to speed takes as much time as actually DOING the work (which, in my case, would likely involve code) so it doesn't seem to make sense to bother keeping on top of all of it. I never feel like I can get deep enough into an issue to understand it fully to make informed actions toward a solution. Not to mention that, in many cases, there is just way, way too much unmanaged chatter.

Context is the only word that I can come up with that seems to embody what I'd like to see. What mgifford said above about contextual information is the closest thing I've heard. Ideally, it would be great if the dashboard was something that could make somewhat intelligent guesses about what I'd be interested in or what I'm qualified to help out with based on tags/categories/some sort of data instead of being a nicer view of a jumble of stuff that is overwhelming.

I want to be able to come in, scan, see that a particular topic or project that I'm interested in has an actionable item that I can work on and then be able to quickly get the relevant information needed to get to work. I don't want to exhaust myself reading through the little arguments and things that happen throughout the monolithic thread and try to guess if I would be working on something that there is consensus about or whether my efforts will be in vain.

Also, re: unmanaged chatter, a way to quickly see which posts are meaty and which are not so useful would be insanely helpful. We have this points, vote up/down system here on g.d.o, but don't seem to make good use of it.

I hope that sounds useful and not like a whole bunch of complaining! ;)

Hi! Sorry for such a late comment, was way too busy week. I'll try to remember my experience of 6 month ago when I was a total newcomer, a lot of stuff was soo not obvious. And afraid to say it, but a lot of still is not obvious for me.

(All further questions meant rhetorical)

What is Issue queue?
First of, if remember myself half a year ago, - it is not quite clear for me that issue queue exists and what it is actually. If take d.o main page now - there is 1 mention of issues in Refine your search as "Forums and Issues". "I hate forums and never visit those, so what is issues? Something "with" or "like" forums. Don't think I should go there."

There is also link XXXX Issue comments this week. Tells me nothing again. Some issue comments? And where I can see actual issues? I don't remember myself clicking that link more than 1 time overall. And don't remember using that "main page" of all issues at all.

Even if you open that page, it is still not obvious what are issues and for what projects. Above the issue table there is "Download and Extend" title. So where am I? Issues to what projects are they? Is it sort of support part of website - where people ask questions and get help? Or is it sort of development part of website where developers talk about their stuff? And what should I download and extend here? (There is also menu there: "Download and Extend Home", "Drupal Core", "Modules", "Themes" etc. When you click on any of those - you get to new pages not connected to this Issue page and no possibility to go back to it (apart from Back button in a browser)).

Finding issue queue

So as I said above - way to issue queue from main page is not really obvious. Also there is no link to Issue queue from any of the top pages from top menu such as Get started page, or Community and support etc. You see links to forums, you see links to g.d.o and many other places, but not issue queue (there are links to issues on Community and support page in "Recent activity" panel on the right, but there are not only issues there I guess, and no way to distinguish issues from other types of content).

Mostly I got into issue queue from specific module page - I found some module, read about it and opened it's issues. When you are at the issue queue of specific module there is no indication that other issue queues exist somewhere, nor there is a way to get to them. Feels like they all are totally separated.

It is really hard to find some issue unless you purposefully search for it. Most of the times I get to know about specific issue when someone gives direct link to it either on irc or twitter etc.

Following issue queue

Once you found issue you are interested in - there is no easy way to see similar issues or follow certain type of issues.

Email subscription was discussed many times already. I find it the most amusing experience since it took me couple of month to figure how to subscribe for a single issue. No kidding.

So via email its either all issues for the project, 1 by 1 chosen issue using spam "subscribe comment" or nothing.

I tried also following issues via RSS, but it is not the case also. For example I subscribed to "Issues for Drupal.org customizations" RSS. And 5 minutes ago I saw new item on the RSS feed - I open it and see "February 21 2009" and text of the issue which was posted 2 years ago. It tells me nothing of what actually happened now - was there new comment? what did it say? was the issue closed? was it just reopened?

Issue queue vs Forums vs Groups.d.o
It is still not really clear what stuff should go to issue queue, what to forums, what to g.d.o. The best example - I remember during D7 release translation effort we had an g.d.o wiki page and an issue on a similar topic. And half of people never saw issue and only commented on wiki page, other people never saw wiki page. And third people saw both and had to constantly manually sync information in both places.

Opening an issue
So many settings this "Create new issue" form has. What should I put and where? There definitely should be a handbook on this matter! Maybe I missed it?

I remember this in connection to general feeling of first weeks on d.o - too overwhelming information-wise. There were tons of different instructions for everything (which is probably a good thing), but it just felt like its too much a bit. Anywhere you go you stumble across link to some handbook page telling you how you should do this and that. And this page always has links to couple of other pages with instructions. And those also have more links and advice some other guides and some more guides just in case. In the end it just feels overwhelming and you get scared that maybe you actually missed something after all.

Closing an issue
As was said already by others - it is not clear usually if I can close an issue. Do I actually have right? Maybe some special people should do it?

Thats it, in short. My general feeling about issue queue I can describe in next way "Since everyone is successfully using it, they all probably know some secret, I am sure I am just missing something important to start properly using it too". I'd be happy if you tell me the secret now. :) Or if I was not all wrong there - I'd be happy to help improving the issue queue.

I think it was about a year before I realized the distinction between projects, forums, groups, and documentation pages. That projects (a module, a theme, an installation profile or a translation) have an issue queue, I think that is right, and the other do not.

This confusion was exemplified for me on the old drupal.org site. At the top of the home page there were 8 links two of which were Paid services and Jobs. I thought the distinction was that Paid services was for freelance work and Jobs was for full time employment. No the difference was one was a group and one was a forum, both jobs boards.

It would nice to have a prominent explanation of these different tools.

In most issues, there are some comments that contain more and better information than the starting post, while other comments are pointless ("subscribe" or "+1") or distracting.

The starting post might be a superficial description of symptoms, but then comment in number 3 an expert jumps on the boat and explains the real problem. Then in comment number 7 we see a patch, and in comment number 11 we see a nice summary. As the issue evolves, there might be two series of patches by different people, that follow two different ideas of implementation.

As a new reader, it is sometimes really hard to decide which comments to read and which comments to skip. And on second read, or when coming back after some time, it is hard to find the piece of text one was looking for.

How can we improve the situation?
- Classify/tag comments as "summary" or "nice patch" or "good idea". This could be done by the comment author or by readers (in combination with a categorized rating).
- Scan the comment text for links to other comments (in the same issue), to identify different chains of discussion. Do this in a way that people can learn how they need to post their links to achieve the desired effect.
- Scan patches for similarity, and identify followups.

All of this is easier said than done. I think the easiest is the to mark summary comments as such. Actually this has already been proposed somewhere. All the rest needs further brainstorming.