Add "concept needs feedback" issue status

Sorry, I should have mentioned this elsewhere, but requests for new and/or renamed issue status values belong in the webmasters issue queue, not the project_issue queue, since these are just admin settings on d.o. I won't be hard-coding all of this stuff into project_issue (though I might update the defaults someday). We don't need patches against project_issue to make this change, we just need one of us with 'Administer projects' permission to go in and click it into existance.

That said, it sounds like "concept needs feedback" is a reasonable status, and could help improve the workflow. Therefore, I support this change. Would just like a few more +1's from the Big Players(tm) before I run off and do it.

p.s. Do we need a corresponding "concept needs work"? ;)

Do I count as a Big Player (TM)? {big grin} :-D

+1 for "concept needs discussion" or something similar.
This is the one that would be used by the whole community of developers.

We have to keep in mind the goals here.
we want:
1) to prevent developers from wasting their time.
2) to make sure Dries would be happy to commit such a feature/API, etc, provided the code is right.
3) to avoid burdening too much Dries.

Yet, it is Dries' approval that matters the most. The community might approve of a concept, but at the end of the day (the end of the development cycle), it is Dries' opinion that matters.

So I see a pair of statuses that would operate like PNR and RTBC.

PNR (Patch Need Review) are the yellow issues: the whole community can review any patch.
RTBC are green issues: in the best scenario, the core commiters are happy with the patch and commit it.

Similarly we would have:

Concept Needs Discussion, or Concept Needs Review: they would be coded in yellow in the queue, a slightly different shade than PNR. The whole community can discuss the concept and come to a concensus.
then:
Concept Needs Approval (from the Green Team): they would be coded in green in the queue, a slightly different shade than RTBC. It is now Dries' turn to give the Green Light. If he does, coding can begin (issue is set as 'active'). If he doesn't, either the issue is set as 'wont fix', or set back to 'concept needs review' for another round of discussion, to come with a better idea.

Developers do need Dries' feedback very early on. But for him to function effectively, he shouldn't be burdened with half cooked ideas. That's why I think it is necessary to come up with a new pair of statuses, one for the Yellow Team, on for the Green Team.

I still like 'concept needs feedback' better than 'concept needs discussion'. Probably a nit, but to me the word feedback seems more pointed and discussion seems like something that could meander around in all directions.

Anyway, the idea of adding 'concept needs work' is interesting, but maybe more overhead than is needed. Everything needs more work until it either results in a patch or gets marked won't fix.

Adding 'concept needs approval' is also interesting, assuming Dries and other core developers buy into the idea. It would be very nice to have them sign off on the big picture once a plan has been hashed out and before coding is done. But that will only work if they like the idea, otherwise this could end up being another place where issues just get stuck. Unless we require that everything must go through this step before a patch can be accepted, some good ideas might just linger in this queue and make no further progress while other issues, possibly less well thought out, are created that ignore this whole process and go right to creating code for review.

So I'd vote to keep it simple to start and just add one new status -- 'concept needs feedback'.

And be sure to add a custom link in the sidebar so we can easily see what's being discussed :)

I am not sure this is a good idea. But_if_ we add yet another status, then rather "needs feedback". The issue queue with iths linear comments isn't well suited for a ful blown discussion. Also, I think it should be easy to make a simply active issue and point it to a discussion in the forums.

Moving the discussion completely off the queue and into a forum is also interesting.

When the discussion has reached a certain stage, it would require the author to nag (by email, on the dev list, on IRC??) Dries for the Concept Approval. The dev would then open a new issue, point to the post where Dries said 'OK', and start coding.

But in long drawn out discussion, one would have to make sure what Dries said 'OK' to.

But why not?

I agree that the issue queue is not well suited for discussion, but I've tried pointing to forums to get more discussion on an issue before and people don't follow you over there, they keep posting feedback in the issue and then you have some comments in the issue and some in the forum and it gets completely unusable and impossible to follow.

And if we use forums for this instead, then once the idea is 'hatched' and ready to start coding, all the background discussion is somewhere else, and there have been many issues where I have seen complaints that it is too hard to figure out what is going on when the discussion is scattered around.

Whichever place becomes the 'official' place for 'concept needs discussion', I hope we can still have a custom link to see those discussions.

I find a better place for soliciting developer opinions on a topic is groups.drupal.org, rather than the forums, so would recommend using that for 'needs feedback' ... almost all developers are already following at least a couple groups, and we also can use wiki pages over there, which is kind of nice.

If there is a designated 'official' place, then people can be reminded to follow the protocol and reply where appropriate.

I am coming back to the idea that we need to make sure there is no misunderstanding as to which 'concept' has actually been approved.

I am thinking that a concept could be written in a plain txt file, and attached to an issue as if it were a patch. Writing text is as easy as writing a forum post. There is no need to have a clean checkout, no need for patching, and no failing hunks.
But then, after the community has agreed with a proposal as explained is a specific file, Dries can say: yes, I approve what's in that file and there won't be any misunderstanding. Prior discussion could take place in the forum or at g.d.o (Dries may or may not intervene there). When concensus has been achieved, the proposal is put in txt (or html) form and attached to an issue for Dries to review. This way, there can't be any misunderstanding about what was wanted and approved (like in the book patch).

On topic, see also my latest reply to Dries on the dev list (Ideal workflow).

@crell, about the "concept needs Approval", you clearly misunderstand what we are talking about. Maybe a better name could be found.

This has to be understood within the context of the recent code freeze and the long discussion in the dev list.

This new status is obviously not meant to be a required step. We are not requesting that everybody goes through the "Concept needs feedback" / "Concept needs Approval" stages. On the contrary: most issues wouldn't need to. Bugfixes wouldn't need to. Most small features wouldn't need to. Nobody would have to go through these stages.

But after the Deletion API fiasco, and the still uncertain fate of pwolanin's book patch, a dev could be wary of going ahead coding a large API change without knowing beforehand whether Dries likes the concept or not. Those new statuses are meant to allow the developers who want to to get feedback early in the process, before any code is written.

We don't want to overwhelm Dries with requests for concept review, that's why the concepts could be screened and commented on by the wider community ("Concept Needs Feedback"), and once the developer has received enough positive feedback, he has the possibility to get a formal approval from Dries ("Concept Needs Approval") : this way the developer can code a large-ish API in the confidence that he has Dries' s thumb up on a specific concept (the .txt file attached on the issue that Dries has approved).

Karen's comment in #4 is crucial here: Dries and core developers (the Green Team) must buy into the idea and play along. If they don't, the proposal is pointless.

So, Crell, even if this proposal went ahead, you would still be free to:
1) ignore concept feedback requests,
2) not review large API patches,
3) go ahead and code any patch you want, including very large API, even if you never asked for any feedback on the concept. Everyone is able to take their own responsibility.

The proposal is especially meant for more newbie developers who may not be fully aware of how things are done within Drupal, and who may not feel confident to spend time coding a large patch without some kind of assurance.

Crell, I am very confused by your answer. I am not sure you understood anything I wrote above.

I'll try to clarify.

@beginner: Um. Please look at the name at the top of this issue. :-) I do know what I proposed, and that it's an optional "phase".

I replied in #11 to clarify that I, too, was speaking of an optional phase. So, we agree, don't we?

In #10, you wrote: "Not everything needs a formal sign-off from Dries before code can begin."
In #11, I replied: obviously not!

Where's the problem?

My point is that no, not everything needs to be formally accepted by Dries. Sometimes it could even just be "I want feedback and suggestions on how to code this".

I replied in #11 to clarify that I, too, meant that not everything needs to be formally accepted by Dries. So, we agree, don't we?

Will Dries not even read an issue marked "needs feedback" until it gets changed to "needs approval to proceed"? I don't know, ask him. :-)

If you had read and understood #11, you'd know I suggested was a way to give insurance that a coder won't waste his time, while not create an administrative monster that would overwhelm Dries.
I proceed similarly with this issue: I propose an idea, and try to build consensus among developers with it. If we do, then and only then, do we bother Dries with it. He is busy enough already to bother him with ideas that don't pass the first hurdle: the +1's from the community.

I just don't see much value in a formal "contract" that gets approval before it can proceed.

If you had read and understood #11, you would know that, even with my proposal, any coding can proceed regardless of everything else. Nothing would change for people like you who are confident enough to code large patches patches without prior community and possibly commiter review of the concept.

Ask hunmonk and co. if they would have preferred spending some time with Dries talking about a concept AFTER their large patch has been refused, or BEFORE they start coding.

You may not see value in it. Fine. Don't use this process, then.
Others might see value it it.

KISS. It's not like adding another status ("concept needs work" or "concept needs Dries' blessing" or whatever) is that hard to add if it turns out we need to further filter concept threads after all.

Please do read what I write before you reply to me. Your reply is confusing because it implies I said things while what I said is the opposite.

Remember the context of this whole discussion.
Since it is Dries who, even among core commiters, has the final say on the fate of any patch, we want to create a simple mechanism that allows developers to have some kind of reassurance that they are not going to waste their time, while not over-burdening Dries with requests for comments.

Re: KISS -- yes, please. I'm already a little worried about the overwhelming choices for status for new users who are just trying to report bugs or request features or support. It's already a dizzying array of options. Yes, we need more, and some should be renamed, etc. But, let's not go overboard.

To this end, we *could* massively simplify the choices for new users by having a new role on d.o for "advanced issue queue user". auth user would just get a basic set of choices. adv users would get all perms. the only trick here is giving users a way to bump themselves into advanced users without requiring d.o admin intervention all the time. we could just form_alter() a checkbox into their profile via project_issue, and behind the scenes implement it by adding/removing them from this particular role or something.

What do you both mean by KISS?
Adding one more status is KISS enough, but adding two more statuses for the purposes I have already stated, is not KISS anymore?

My earliest proposal was even more KISS: remove one status (RTBC) by default (using perms) and only keep it for developers who are experienced enough in the Drupal ways to know when and how to use it. Even this simple idea was nuked.

I am not too sure how to feel about the whole thing.

KISS == keep it simple, stupid.

I was mostly talking to myself. I was the one who proposed the extra "concept needs work". ;)

My only point is that:
a) Yes, we need lots of status values to properly reflect the reality of how many states an issue can be in, to help manage expectations and prevent people from wasting time or getting frustrated.
b) A huge # of status values can be overwhelming for people new to the issue queue.
c) We need to balance (a) and (b).

An extra status seems like it would be even more useful now, since the testbot reacts to "code needs review" in a particular way, making that more narrow than it used to be.

How about something like this:

active (solution proposed)

I think that might be the simplest because it does not presuppose whether it is feedback/discussion/approval/etc that is needed in response, just points out that the issue contains a specific implementation idea. It also might be more versatile, because in addition to the "I want to rewrite Drupal"-type issues, it could be used for smaller things as well (support requests, for example). And it keeps things relatively simple, since although it adds a new status, there are still only two main "families" of statuses ('active' and 'patch'), like before.

I agree that it should be kept as simple as possible, but it doesn't also make sense to use patch (needs work) when there isn't a patch attached to the report.

Or the statuses are generic enough to be used in more circumstances, or a new status should be added. Keep it simple, stupid doesn't mean that the terminology used should be always reduced to the minimum number of words. It would be like to reduce the number of words used in English to 140; would that make English simpler?

I side with the original "concept needs feedback"

+1 for the feature.
I right replied to a feature report, for which the concepts need feedback could have been useful.

active (needs info) usually makes people think that the informations are required by who submitted the report, so it's rare they add a comment if they don't have the same problem; concepts need feedback would make explicit that the maintainer(s) are looking for some feedback, before to change something.

I think that the difference between active (needs info), and concepts need feedback is like the difference between a blog node, and a poll node: with the last content type who visits the web site visits that page if he wants to vote on the topic given by the title.

I am setting this report as duplicate of #171350: Reorganise project issue statuses.