[META] Drupal.org ideation tool

separated description into motivation and proposed resolution.

embedded mock ups.

html to format list, add issue numbers. will update those issues.

updated who will actually implement the tool (DA staff).

added a place for historical context links.

I think it's important to have a voting system to make it even easier to gauge community interest. No need to implement downvoting, but an authenticated user should be able to upvote a suggestion. Would prevent "me too!" comments on each suggestion.

Like the idea of offering up-votes; I'd give that an up-vote if I could!

What would you think of: instead of relying on users to stick to the template (with subheads for benefits, risks, etc.), create separate fields for those items? Perhaps we could then make it easier to do "Drupal-ly" things with the feedback, like with searching or sorting or filtering by individual fields, etc. Also along those lines, what about using a taxonomy vocabulary with some pre-set categories, nothing too crazy, maybe offer terms like "interface", "back-end", "search", and…??

Thanks for pursuing this!

I think eventually voting makes sense, though I argued a lot to keep it off the initial version of this tool. Voting is a complex topic. How do we gauge interest that's *currently* relevant versus just has managed to build up over time, how do we balance the fact that some people have a much wider base of podcast listeners/Twitter followers/etc. through which to promote their features/ideas where others don't, how do we also deal with the fact that just because an idea is popular (like closing the forums in favour of Stack Exchange) doesn't mean we'll actually do it? Do we let anyone with an account vote? If so, how do we deal with abuse/spam? etc.

I think there are other ways of gauging community interest (comments, interest to work on it, etc.), and would prefer to start with those rather than get into the politics of voting straight-off, personally.

I actually think downvoting is just as important as upvoting. It's warm and fuzzy to say "never be negative", but realistically, people can suggest something that another person thinks is a *really bad idea*, and they should have just as much ability for that information to be captured. (Their reasons for thinking it's a bad idea could be stupid, but someone's reason for thinking it's a good idea could be no less stupid.)

That said, I do like direct voting in addition to commenting as a way to reduce the chatter. webchick's concerns in #11 are not invalid, but they're the exact reason we've shyed away from doing anything in this regard for years: Fear that we may not get it right and it will be game-able. Let me be clear: We are NOT going to get it right, and it WILL be gameable. Not doing so is also gameable, just in a different way. Comments are a really poor way to gauge overall interest; just interest from people with the time/interest/energy/obsession to waste non-small parts of their lives writing out arguments they hope are convincing. Just because someone doesn't have the time to write a 5 paragraph essay in an issue queue doesn't mean their view is less valid, especially when we're talking about changes to serve our user base (ie, customers) so the "do-ocracy" doesn't apply in the first place.

Remember: Voting on issues doesn't imply that we have to work on things in that order. It's a feedback tool to provide useful data to the implementation leadership team. As long as we set that expectation (no, just because something got more votes doesn't mean we'll always do it first) it should be fine. Many project bug trackers (both commercial and open source) support this functionality and it works out fine.

Maybe calling it polling rather than voting if you're really worried about it.

Well for starters votes could be hidden for general users and only visibly by admins. You don't even have to sort by the votes to start, but admins should have the ability to use that to gauge community interest.

Otherwise aren't you leaving it up to the admins to decide which is a higher priority? Wouldn't it be better for the users to decide? Without some sort of polling, it seems like the only way a user could indicate interest is to write a comment - but the comment text may be useless.

EDIT: Seems like the functionality would be very similar to "follow this issue" that was introduced. It could a button "I'm interested" or something that does the same thing. Would hate to have a new version of those old "subscribe" comments attached to this tool.

is there really no existing tool out there that could serve our needs?

UserVoice is similar. See how Digital Ocean uses it: http://digitalocean.uservoice.com/forums/136585-digitalocean

when discussing voting, the DSWG was not in agreement, and so we decided to table voting implementation details so we could move forward with other things we *did* have agreement on. opened separate issue so that ideas can be explored there. #2263057: Voting on Drupal.org ideas (ideation tool nodes)

Question in #14 by @sdboyer is a good one. I added a place in the issue summary motivation so we can clarify that. (might need some comments also to explain)

> Well for starters votes could be hidden for general users and only visibly by admins.

I don't think we would do this. We want the process to be fairly transparent.

The priority is a complex subject and isn't going to be decided by just this tool alone. If an idea is approved and moves forward, its priority will have to be discussed by affected groups/teams and we'll have to see how it can be worked into the overall roadmap for changes. Community interest will, of course, be a factor, but there will be many factors to consider.

If we keep this in house, we should do it in a really quick and simple way. Outsourcing looms more attractive the more complicated we make it.

Have we discussed using the Project Issue for this? It looks like it can handle additional content types, not just project_issue nodes. See http://drupalcode.org/project/project_issue.git/blob/refs/heads/7.x-2.x:...

From the Summary, the non-trivial functionality is:

1. Email notifications. I don't know of a trivial way to implement all those variants. I suggest that folks use RSS or a free RSS-to-Email service if they prefer email. See http://blogtrottr.com/, among others.
2. Workflow. I think this could be cut, if we are trying to save money.

is there really no existing tool out there that could serve our needs?

Yes, there are tons of other sites that do this and are not built on Drupal, including completely free (as in cost) ones. We used such a system back in 2012 for the ideation process at http://drupal-association.ideascale.com. (And ironically got more participation (about 2x iirc) on an external tool versus the internal, g.d.o-version we did in 2013: https://groups.drupal.org/drupal-org-2014-roadmap-brainstorming)

I believe the rationale for keeping it on *.Drupal.org was to allow things to more easily move to/from the deployment tracking tool, though I've pinged tvn for a more thorough response.

Re #18 indeed, we are all very much aligned with not inventing any wheels for this. The idea is to keep it as simple as possible (CCK + Views) and using only other modules that are already used on *.Drupal.org.

I think that we need votes up to rank the bests ideas.

Like:
http://askubuntu.com/questions?sort=votes
http://www.preapps.com/top-app-ideas
http://windowsphone.uservoice.com/

Since YesCT requested it, added a "history" section in the issue summary talking about what attempts have been made prior to this.

So what I'm hearing so far from the discussion is that despite problems there may be with voting (enumerated in part in #11), the respondents so far feel that this is a pretty critical component of the system as a means of giving community members a voice. I can see this argument. It also allows for people to engage without necessarily signing up for arguing in public (often with people with vastly more karma than them), which means more inclusiveness too. I think it's just a matter then of setting expectations properly, per David Hernandez: "Community interest will, of course, be a factor, but there will be many factors to consider."

So let's assume that a voting feature is going to happen (either with the initial roll-out or shortly thereafter), and move the finer points of implementation at the dedicated issue for this at #2263057: Voting on Drupal.org ideas (ideation tool nodes) (thanks, YesCT).

The other theme that's clearly coming up is "Why use Drupal at all for this? And if we use Drupal for this, can we just re-use existing tools we already know (e.g. Project module)?" These are all valid questions. I would however like to siphon those off as well, so also opened up #2263117: Drupal.org ideation tool implementation for that discussion.

Let's try keep this issue focused on whether or not this tool (however it's implemented under the hood) will actually be sufficient for community members, working groups, etc. to propose and prioritize features from the community. There's no point in building something no one will actually use. :D

We need a custom tool (instead of g.d.o posts or d.o issues or ??) because [??]

I would really want to see the 2 question marks after "because" replaced by some logical reasons. Changing a tool without knowing why is a really bad plan in every situation.
I don't see which problems are solved comparing to current issue queue. To me this seems like a content type "idea" based on project issue node with some small additional features, therefore I hope this will not be implemented from scratch, but will improve the project_issue module.

Pasqualle, I'm trying to make sure I understand your concern. Are you referring to a change to existing project issue queues? We aren't changing those. This project is a tool specifically for submitting ideas for changes to drupal.org. The tool will likely live on infrastructure.drupal.org

First of all, I'd like to say that this is a great idea! I think we have spoken about this several times leading up to D7UX and in the Prairie initiative but it never got far enough to actually materialize as a plan. The approach here should at some point be enough to aid in Drupal core/contrib its understanding of audience needs and ideas. I have a bit of a bias as I put out several proposals, albeit for Drupal core. But with a similar intend of communicating the value of an idea, gauging the right kind of feedback and making sure it gets done.

Workflow
The draft state is a little vague to me, while I understand that we want to support this state in this tool. For me personally it would be completely illogical to go through the draft and initial feedback on such a public platform. With any of the "proposals" that the UX team goes through, we tend to spend most of our time writing up the actual rationale and complexions. Going through that process from "raw" to "complete" draft in the open sounds very scary. From what I have learned the community responds great to very detailed proposals, and eats you when you put out something without clearly explaining all the ins and the outs.

While it can support draft states, I wouldn't focus on it too much. It's much more likely a good IRC conversation or a google doc, will lay the foundation to a good proposal. Not a whole feedback system. Personally I would not use this system for such feedback, I would rely on more rich communication platforms to support this (like chat, skype or google docs). I'd like to be in control in who I can draw in for feedback when I am in the early draft state. I dont want to bug webchick/dries/drumm with stupid or more common, ideas that aren't thought through enough.

I don't think it makes a lot of sense for this platform to support the very early "rough" ideas of one/two paragraphs. Ideas that are posted on this platform should be more complete than what we find in groups or issue queues. So the larger community can truly evaluate them. I imagine a workflow like this:

1) The contributor works on the idea (outside the platform).
2) Gets some initial feedback from the component maintainer, to significantly improve idea (outside platform).
3) The full proposal gets posted on the platform, gets loads of community feedback.
4) The component maintainer, sets the idea to proceed or stop.
5) The component maintainer, sets a clear progress indicator (%) and status.

This just an idea though, I imagine less connected people might feel more need for feedback from component maintainers. But even then I would decrease the focus on this workflow. It's just likely a more rich process for these early drafts can be done through other mediums.

I'd like to see how a project page looks. Ideally the page understands the different states a proposal can be in, and elevates different information because when its approved people want to know what needs to be done to get it rolling and when its rolling people want to know 1) how to help out, 2) where its at.

With a community as large as Drupal, its easy for this platform to get swamped with (incomplete) ideas and unclear approved ideas (where people don't know, where its at). Putting some more clear boundaries in place might help make sure weg get more full proposals, and the status of running ideas are better managed . Sometimes adding something like a % is all thats needed.

Interaction design

I understand that these are still very rough drafts. But I hope that this gets a good look from a design perspective. There are a few things I notice that probably won't work that well (only one author, focus on filters, few topic categories). There are many platforms to draw inspiration from as earier commenters already posted, I'd like to put forth http://www.openideo.com/ who have done a great job at clearly communicating phases, progress and ideas.

The project page should somehow capture clearly the status and provide a more scannable format of ideas. The whole issue summary is mostly just that, a scannable version of the issue. Ideally the summary, is not an "open ended" thing but there are clear fields you have to fill out. You should name the benefits, you should name the risks, you should name how to measure something - I don't think we need to make that optional. Making it requires allows us to apply structure and design these elements.

We should also add a way to capture discussion points, like an FAQ. It would be good if the summary can capture very important feedback and summarise the response on it. That would make for a more clearly guided feedback process. Something that is often missed is a good connection between the ideas and the feedback of the creator, we try very hard with the ux team to capture that. But in the idea phase its near impossible, as opposed to when patches are rolling.

Voting
I think @webchick's conclusion is spot on and I am happy to see that this will in someway make it into the project. We should have a bit of a balance between "new" ideas and top voted ideas then.

Timeline
The proposed timeline already seems quite short to get feedback from important stakeholders. It is already too short to make sure we somewhat of a good design, and its waay too short to make sure we build something solid that we can work from. I am sure the DA staff have loads of things to do before Drupalcon, so unless the "initial version" is a sandbox to which people can contribute I wouldn't rush this project too much.

Where are you discussing what? I just made 3 comments on your groups.drupal.org post at https://groups.drupal.org/node/379718 that might belong here... All three of the comments I made there just now are relevant to the idea-gathering process, since I read the proposal linked in your main post and commented about it, and only just now I noticed YesCT's comment that linked here (PLEASE go edit your main post and make it clear where you want the responses, and put links to the issues which apparently are trumping the proposal that I just wasted time reading apparently).

So, regarding this issue... The discussion on this issue (aside from Bojhan's comment #29, which is more comprehensive) seems entirely to be concerned about voting. Which, from what I have seen, is really not going to be a great way to make a decision about what needs to be done on drupal.org. We have all these governance groups that are now given the mandate for "define the tools and processes for X" and now you're saying the process is "put ideas out there and let the community decide" -- then why do we need to have WGs at all in these areas? If we're going to have a community-driven process for deciding what gets done on d.o, which is maybe OK, then we need to amend all the WG charters and get them working on other things besides deciding what tools they need. (This applies to the Docs WG specifically, and probably others.)

Voting should not take the place of thoughtful community input, and even that should not take the place of a committee that is knowledgeable in an area taking time to deliberate about the best course of action.

jhodgdon, I think much of what you're saying in your g.d.o comments is correct. We want the idea submission process to be as simple as possible, and as accessible as possible to the entire community, regardless of experience level or area of interest. Determining the technical feasibility of an idea, and coming up with an implementation plan, will not be the responsibility of the person submitting the idea. It will be the responsibility of the d.o groups/teams, and/or other relevant parties, to determine.

What we want to make sure of, with regards to this ideation tool, is whether we are gathering the appropriate information. Do these fields make sense? Will we have the right information for team members to easily find ideas relevant to their areas of responsibility. Will we have the right information for the community to find ideas they are interested in? Are we missing a component that should be integrated? Does the tool make sense for the workflow we envision and vice versa?

We want to get as much feedback as possible on the tool itself (We realize the timeframe is very short) so when it is built we have something the community can use, and will make sense for what we are trying to accomplish.

I had an email request to provide feedback and two questions instantly came to mind from a quick scan of the threads:

What is the need and does this help?
As per the issue summary "We need to do better in engaging a wider pool of our target audience."

From my limited knowledge here, the biggest issue is the lack of visibility for general users about these threads.

So a few aggregator feeds of these feature requests back to some blocks on drupal.org or something similar would probably provide more community involvement. Even just a "Features request / voting link" on the project, that creates new block in the projects pages to provide a link to the tool. Then other projects could also use it. This block should be visible in both the issue queues and main page.

Secondly, a new mailing list of hot topics related to Drupal as a whole would probably interest most members of the community, of which a section could be dedicated to new features for drupal.org, even if these were just to ignite some interest to going to whatever tool is used to participate. Possible content; general status of core, pick a hot new theme or module to review (Module Monday comes to mind), something to direct users to participate like to this tool or any other active initiatives like the drupal.org 7.x upgrade, maybe other things like upcoming DrupalCons, new showcase, other interesting posts or policy's, ... More importantly, I think it would drive up more community involvement of Drupal as a whole.

Why not outsource?
These general features are already handled nicely from the external tools and drupal.stackexchange.com is already taking over support. From the introductory sentence, this decision already seems to have been made? I have missed the pro's / con's section behind this decision.

General feedback

idea submission process to be as simple as possible, and as accessible as possible to the entire community

Users are generally lazy, so I agree with this. I know that I would generally just read the intro to any new feature and just want to vote it up or down. When voting down, I would probably add a comment too, but enforcing this may put people off from participating.

@jhodgdon in #30: Hm. https://groups.drupal.org/node/379718 is like 6 months old, and while it provides the background on the overall development process this tool is intended to fit into, it's definitely not what we were asking for feedback on right now. Nevertheless, thanks for the feedback! (I'm curious how you found your way there, though...)

Regarding how WGs fit in, this is exactly why we wanted feedback from the WG members themselves to see if this tool / process worked for them (in an ideal world, this would've been done before posting for wider public feedback but we really wanted to have something for folks to poke at by Austin if possible). The thinking was that while the WGs / D.o Tools Teams still ultimately "own" the roadmap of their respective parts of Drupal.org, and as the primary overseers of those parts of the site probably know better than anyone what should happen where and in what sequence, nevertheless it can be still be useful to get "bottom-up" ideas from the wider community, particularly those who wish to put some time/coding/funding/whatever behind their requests. So the idea would be that as part of the periodic WG meetings, a standing item would be for teams to eyeball the list of D.o ideas in their area that'd come in / been updated since last time and make some kind of call on them: "Wow, great idea, we're adding it to the roadmap," "Good idea! Not a current priority for us though, but if you want to work on it, fill yer boots," "Hm. We don't feel like this has consensus yet, keep discussing," "Sorry, but there's absolutely no way we're ever going to implement this, because it's directly in conflict with X other thing," or whatever. The idea is that this tool (whatever it manifests itself as) would be the single way for the wider community to interface with all the appropriate WGs without having to understand all the nuances of community structure, and all of the people involved and who to ping about what. And similarly, WGs wouldn't have to scour 30+ issue queues for Random Community Ideas that need feedback.

Does that make sense?

@Bojhan in #29: Awesome! Thanks so much for the detailed feedback!

Regarding draft states, I think if someone is enough of a community insider that they know who best in the 1m+ user community to ping to get pre-emptive feedback about an idea, has the personal relationships with those people such that they can send random emails/IRC pings to those people and ask them to review things in Google Docs and get that followed through on (which of course requires knowing the e-mail addresses of those people and IRC channels those people hang out in in the first place), they can probably skip draft mode. But I want to emphasize that this will only be a minuscule, minuscule fraction of the community. Everyone else is going to come at this from "I'm a Drupal.org user, and I have an idea." The goal of this tool is not to require a Masters Degree in How The Drupal Community Works™ in order to propose something. (This "20-100 hours of up-front work and leveraging personal relationships with the top ~20 Drupal.org community leaders" is currently what's needed to successfully suggest a change to Drupal.org that has a hope in hell of being deployed, in almost all cases. But this needs to stop. It's incredibly disrespectful of peoples' time when it doesn't pan out (which is often), and Drupal.org is a website that needs to serve far more than deeply-embedded community insiders.)

So I'd rather flip that idea on its head. We should assume that most people will start with a rough idea and then subsequently go through the proposal refinement process in public (with the help of others who support the idea). Ideas on how we can make that process less scary? Ideas on how to make the idea template such that the original proposal is more fleshed out and useful to the WGs/teams who need to curate them? Or, ideas on how to do what you say in a way that someone who just started using Drupal yesterday and has a great suggestions for improving what they saw through "new eyes" can do? (They obviously will have no idea who component maintainers are, that there are even such a thing as component maintainers, etc.)

I really love some of the UX around http://www.openideo.com/ I hope that's something we can eventually evolve this tool to become. The initial version will probably look extremely "Drupally," though. :) We view this as a low-level plumbing thing needed to move Drupal.org along and not something that we should expend huge amount of resources on, including maintenance. The more custom and one-off it is, the higher those costs become, and the less work we actually do on Drupal.org itself that directly benefits its respective target audiences.

That said, I think you've highlighted some things people are definitely going to want to know, namely "this is where it's at," and "here's how you make it happen faster." I don't think that's necessarily clear in the current mocks. The points about multiple authors, explicit fields for things like Benfits, Risks, and Metrics, etc. are good ones as well. Not quite sure how to handle the FAQ idea.

I'm also uncomfortable with the timeline, but we're going to try it and see how it works out. We've already gotten really great feedback in < 24 hours, so I'm hopeful by the end of this ~10 days we might have a good idea on where to go in the following 2 weeks. But we can always push that timeframe back if needed.

RE: How I found that GDO post - it showed up in my GDO daily feed... and I didn't look at the date. Possibly because someone put a new comment on it, and I didn't notice it was just the comment that was new and not the post. My bad!

RE #33 - I didn't previously get that this was just the "gathering the wild ideas" tool. The process for WGs themselves to articulate their priorities needs to be defined. Soon, please! :)

So... It seems like the official "Priorities" for each WG need to be posted near this "idea" tool, so that community members will know what is already being worked on or has already been agreed upon, if they're not in the "idea" tool. And also the "work in progress" tool needs to be posted nearby, so we can avoid people posting ideas that are already actually being worked on.

And there still needs to be a way to report bugs -- actually, how will community people tell the difference between "Here's something I think could be improved" (and it's a bug) vs. "Here's something I think could be improved" (and it's an "idea") anyway?

Also, I thought the WGs were supposed to be deciding on the channel(s) for community members to contact them, make suggestions, etc. Won't this new channel just lead to confusion and duplication? I mean, let's say the Docs WG says "To contact us, post in the Documentation project issue queue using one of these two components", and now we have to say "Well, but if it's an 'idea' for Drupal.org, whatever that means, instead you have to put it in this other place and get it voted on, and hopefully we'll see it there too amongst all the other 'ideas'". Or are we supposed to just use this new tool for all Docs-WG contact, and drop the idea of having our own channel for communication?

And it's also annoying that it looks like WG members will now have yet another thing we have to watch (do you know how many issue queue searches I already run every morning?). Will these "ideas" have a *reliable* way I can bookmark a search, to pick out "ideas I'd be interested in knowing about because they're related to documentation", or will I just have to scan them all manually?

I guess... the bottom line for me is that I don't see "we don't have enough ideas being generated from the community" as the major or even a significant problem that is standing in the way of drupal.org being improved. I think the main problems have been in other areas, such as:
- Difficulty of reaching consensus on whether an idea is worthwhile/good or the best possible plan
- People hating change and complaining when anything is changed or proposed to be changed, whether there are good reasons for the change or not
- Community backlash in general or complaining they were imposed upon instead of consulted first
- Not knowing who has the authority to decide a change should/can/must be made
- Too many people can veto an idea (security, infra, and seemingly certain individuals on a whim, like whoever has commit privs to the projects that would need to be modified)
- Large learning curve to learn dev processes for d.o improvements (bzr vs. git, quirks of the custom modules and theme, features, compass/sass, etc.)
- Small changes can impact a lot of different things
- Impediments to development (getting a dev site made, setting up your ssh keys and other environment stuff, etc.)

Sorry, I'm probably ranting. I don't see this as a really important need, and it looks like a big bother to me as a member of the Docs WG... What exactly is this doing for us, besides giving the appearance that community members have a say in directions of d.o, when now the WGs are (I think?) supposed to be making these decisions (with community input as they define it)? I just don't really see how it all works...

@webchick I agree that we need to open this process up for more people to get feedback on their ideas, but if the people who are so highly connected and know the ins and the outs of each change can't even get things done. I am unsure how you expect this tool to help beginners out. This however is largely a contributing to d.o and DA staffing problem which we have made strives to solve. At best we should get a bunch of easy to understand/scan tutorials/videos around this, as I expect it will be really scary for beginners to get loads of feedback they have no clue about. Because the overall concepts are unknown.

@jhodgdon The ideas listed here should be larger than something that could be captured in one issue. It is a larger idea, like adding a reputation system to d.o or adding project reviews. The line between what belongs in the queue and what belongs in this tool should be drawn at scope. The smaller scope should will often be in the issue queue.

There is a real risk that this turns into "yet another channel" and thats totally true. What it could also be is another channel that is very rich in its interaction and communication to the outside world. Something groups never really became. For most outsiders its near impossible to know what each WG is up to (even connected people), so having their official projects somewhere in a clear communication channel is I think quite beneficial. I don't think its an end-all for communication of a WG, but it can serve as a tool for outreach and communication more so than blogs, docs or meta issues can be. I think most of our ideas will overlap with the larger community, and having a place for them thats easy to reach and easy to understand will make a world of difference.

I also have my concerns, with D7UX we had way too many communication channels from a blog that was heavily posted on to groups to issue queues. It made it unmanagable. But I also saw the great value in reaching more people.

That said. It does not resolve any of the points you mention, it doesn't make the process of getting changes done any easier. It's clear we don't necessarily need more ideas, we need action on getting the ideas done (to be quite frank, I thought the WG had more ability to make changes - so far its mostly supporting targets from the DA). But a way to get them done is to get more eyes on it. It won't be a magical solution to the reality that is working in the community, I think all the points that you raise will still occur - but I've largely come to accept that is part of working in the community.

I think tvn's proposal is clear on the fact that component maintainers have a deciding role, in moving things from proposal to agreed, to in progress. I am hopeful that this tool will support any WG in their process, even if it just for communication.

Wait. So I asked in # if this is the place where the WGs put their ideas (because I don't think this is a good tool for the WG to use), and I'm told "no, calm down, this not for the WGs to use to propose ideas, it is for community members to propose ideas". So I don't see how this is going to help the WGs communicate what they've already decided on.

So... Let's step back here. Go to https://drupal.org/governance

We have:
- Documentation WG: "acts as a group to maintain the guidelines and processes for documentation, and to recommend and guide development of tools and infrastructure that are needed for documentation." [from the charter]
- Technical WG: " make sure that the Drupal project has efficient technical policies, procedures, and standards as required to keep the "technical" side of our community operating smoothly. ... The TWG may also develop guidelines and/or recommendations regarding the introduction of new tools and technologies for the benefit of the community." [from the About page]
- D.o software WG: "provide the tools and processes for the community to make Drupal.org an extraordinary experience for evaluators, site builders, and contributors alike, and a shining example of what Drupal can do. ... DSWG appoints and empowers different teams, each responsible for a particular aspect of the Drupal.org websites ... Ideation: Working with the different Drupal.org target audiences (e.g. contributors, evaluators, site builders, etc) to understand their needs and coordinate with the different [I'm assuming d.o software group sub-]teams on implementation. ... Planning: Collaborate with the Drupal community, the Drupal Association Board of Directors, and individual [d.o software group sub-]teams on maintaining an up-to-date plan for the Drupal.org websites that includes a prioritized feature roadmap ... ] [from the charter, except stuff in [] is mine]
==> D.o Software team "Developer": has authority over all the tools developers use [paraphrasing]
==> D.o Software team "Community": has authority over forums, groups, and stuff like that [paraphrasing]

So I see where my confusion is coming from. It seems like the Governance charters have granted the ability to develop guidelines and recommendations for "tools" in a couple of areas (which I would interpret as being drupal.org software, because what other tools do we have?) to the Technical and Documentation WGs, and the ability for those groups to define their own processes for communication, idea gathering, and decision making. But the D.o Software WG also has the authority to gather ideas and decide what gets done on d.o.

This really needs to be clarified -- I don't see how we can have two separate teams having idea-gathering and decision-making authority for the same thing (d.o software tools). If ultimately the Docs WG and Technical WG do not have the authority to make decisions about the tools (d.o software) that affect their areas, through their own process (which, as in their charters, is supposed to involve community input), then we should take that part out of our charters.

The Docs WG has been deliberating for several weeks now about what the priorities should be for Documentation tools, and you can guess that after we have come to conclusions (with whatever community input we gather), we are not going to be happy if the next step is "OK, now you have to get this through the Software WG, so put these into 'Ideas' and let the community vote on them". And once we have our vision/priorities in place, if the community proposes an idea related to docs tools on the Software WG's "ideation" tool, and it bubbles up to the top, but doesn't really fit into the carefully crafted plan of the Docs WG -- which is the Software WG going to listen to? And if someone in the community takes on the project of making that idea a feasible reality, and the Docs WG is against it, will it be deployed? [And for all of this, substitute "technical WG" for "docs WG" and see what the answer is.] And who has the authority to decide on tools that affect developers: the D.o Software WG "Developer" team, or the Technical WG? So far, there isn't a D.o "team" that looks like it is in the area of documentation, but once there is, who will have that authority, the D.o Software WG team or the Docs WG?

This tool is not a decision maker, putting all matters up to vote. This tool does not set priorities for the working groups. And this is part of why we hesitated to have voting on the tool, because of that confusion it creates. This tool is simply a big suggestion box for (changes to) drupal.org.

We currently have a dozen different issue queues, half a dozen g.d.o groups, a bunch of irc channels, etc, where people can post their ideas and try to get support. We are trying to consolidate that into one place where we can tell people to post their ideas, and where we can see ideas the community is generating. We don't want people to have to navigate through the complex ecosystem that is the Drupal community to suggest an idea. If a random community member has an idea for drupal.org, like "Hey, I think there should be user pictures on all posts," we don't want the burden to be on them to figure out who is responsible for that piece of technology and post it in just the right place, and then do their own communicating to get people to look at it. We want to tell them that if they have an idea, put it in the ideation tool, and we'll see it. We want the burden on submitters to be low, and have a way to gauge interest and get community feedback.

This will not replace the decision making of working groups, or set their priorities, but we do want to make sure this tool is usable by working groups, so they can see what is posted by the community and use it for guidance. The whole point is that people may suggest things the working groups haven't thought of, or may not realize are real pain points for specific segments of the community.

I agree that how the working groups coordinate with each other, especially where there may be an overlap of responsibility, has not been fleshed out, but this is not the forum to do that. We need to have a more detailed, formal conversation about that. And, again, I want to emphasize that this tool is not intended to have authority over any teams or working groups. It is a tool for people to post their ideas, and, if we approve of the idea, we'll work on making it a reality.

I had the feeling that a Tools Team, or Working Group could decide on a priority, and make issues in their queue, tag them, make changes in the changes tool... and they could make an idea node, and mark it approved and link it to other discussions, changes nodes and issues. And this would provide an overview of what is being worked on, still empowing the teams and work groups to prioritize and make decisions, but still communicating with ... everyone. And it would prevent duplicates (?) because people could see what was already in progress and what the current priorities are.

It seems like some of @jhodgdon's concerns are when would a Team or Working Group be expected to do that (make an idea node for something they are doing or have decided to do) and when would they not be expected to make an idea node. @jhodgdon is that one of the concerns?

Is a more general concern:
what risks are there to having a ideation tool?
what additional work burden does this put on Teams and Working Groups?

So... Just one more question/thing to think about:

Where would Drupal Core 7/8 be if instead of going the route of usability studies and sanctioned Initiatives, it had used an ideation tool like this to gather ideas on what the pain points were in Drupal Core?

I just don't see the value of having this tool. I think it would be a lot better to fund usability studies and focus groups and whatever else you can do to gather thoughts and ideas for improvements in a structured and focused way, rather than having yet another try at a tool where community members can randomly make suggestions. And then take the time to have thoughtful deliberation within a small, focused working groups/team to decide what the priorities are. I don't see how having "idea nodes" helps in either process, and I think these two processes will be vastly better than "idea nodes" at making sure the best ideas get gathered and chosen.

OK... It's not just the Docs WG. It's a larger Governance issue that several charters are granting "decide on tools" authority over the same "tools" to both a WG and a Software Leadership Team. This cannot work well -- one group or the other has to be "the decider", and in any case, it is a waste of time to have two different groups deliberating about the same questions.

The Software WG also needs to decide on whether the other WGs are going to be using the ideation tool for idea input from the community, or to present their ideas to the community, or both. I have gotten different answers from different people in responses above, and it's very confusing.

Spun off the governance/authority issue to #2266431: Need to clarify charters in area of "tools for drupal.org" -- I don't think we really have a disagreement, but the charters IMO need to be clarified.

Feedback on the original fields proposed (What are the benefits, What are the risks, How can we measure the impact of this idea, Are additional resources available for discovery/implementation): I'm skeptical that idea submitters are going to have answers for each of those! I myself am not even sure what the 3rd question is asking

What if it was as simple as
- Summary of idea
- What problem does this solve?

We are also missing a place for submitters to include mockups or video/screencast. Think about Kickstarter...they always have a video to help get others to buy into their idea.

I'm sorta keen on the idea of people becoming 'backers' of an idea (basically, expressing an interest in taking the idea forward / developing the idea).

As for "is this new ideation tool really necessary?" I suspect it is, but I've been out of the loop for awhile.

Thanks all for the very thoughtful feedback here. The DSWG discussed this at our meeting today, and based on some of the extremely valid concerns/question being brought up around process/communication/authority, etc. we're going to be postponing this effort for now, in favor of working on answering those concerns/questions instead. Those concerns/questions affect not only future ideas we might do, but current changes that are being deployed to Drupal.org, and it creates visible friction even now. We also spoke about a general move toward improving the tools used for prioritization/ideation for *all* Drupal projects, not just Drupal.org, though this requires some more thought/planning.

So postponing this issue for the foreseeable future. What this effectively means is we'll be relying on the results of the Q3 2013 brainstorming process at https://groups.drupal.org/drupal-org-2014-roadmap-brainstorming, as well as things that come out of the D.o user research exercise announced at https://assoc.drupal.org/blog/tvn/whitney-hess-lead-drupalorg-user-research, as well as issues that the "subject matter experts" in each of the working groups/d.o teams to form the 2015 roadmap for Drupal.org. For now, I think this is ok, since we need to walk before we can run here, and there's already a huge backlog of stuff we know we want to do that hasn't been tackled yet, let alone searching for new ideas from the community.

But an inclusive ideation process for Drupal.org is in our group's charter, so we will be revisiting this in one way or another in the future, once we feel the "day-to-day" D.o process stuff is smoothed out.

So... where should people currently go to suggest an idea for Drupal.org?

I stumbled on this "issue" while looking for a place to suggest an enhancement to the filters for project modules. (My stumble path was Group "Drupal.org Improvements", group post "New Drupal.org ideation tool proposal", and then this "issue".)

I have not yet seen any place to submit my idea except perhaps in the "Drupal.org Improvements" group. I have not yet seen any of the "over 15 issue queues" that are mentioned in this issue. I asked on IRC #drupal-support about where I should go to suggest my idea but I did not receive a response.

So, I'm going to post in the "Drupal.org Improvements" group. Hopefully that's the right place! :)

Regarding the following bullet point: "Community members need a way to suggest ideas that is not 'open an issue' since the issue queue can be intimidating."

... this is one reason a lot of projects track "Change Requests" rather than "Issues" or "Bugs". The root cause of a Change Request of type "Issue" could be many different things, such as a bug, user error, a bad test script, bad test data, etc. Or, it could be stated up front by the submitter that the Change Request is not of type "Issue" but is instead a "Enhancement Request" or a "Feature Request".

Yes, it's semantics, but terminology can of course mean totally different things to long-time community members versus newcomers.