Hi all.
There’s been various threads/posts recently about folks being upset having their tickets closed as wontfix, instead being pointed to the Forum here for discussion.
The @steering_council have discussed this, and whatever else we might do as a community to help improve the contribution workflows for everyone, we’re agreed there’s a relatively easy change to be made by introducing a new ticket state, for something like Discussion needed, and improving the messaging around that, so that folks don’t feel the tombstone has been shut on their idea before it’s even been considered. (That was never the case, but that’s how folks have reported feeling.)
The idea is that New Features could be resolved with this new state before the discussion, then either moving to Accepted or wontfix depending on the outcome.
We’re looking for some interested volunteers to self-organise and push this effort forward.
The main docs for the Triage Workflow are here:
These would need to be updated to mention the new state, and the flow charts there will need to be updated. I’m sure there are other places to review as well.
At the same time, the new flag would need to be added to Trac. I’m imagining that’s the much smaller part.
(An alternate idea would be just to improve the messaging around wontfix. This can be assessed.)
Finally — and this ties into changes that have already been made — all the signage and supporting materials that guide people where to go could probably do with a review, since ideally folks wouldn’t open a Trac ticket for New Feature requests as a first option anyway. It feels like we could guide folks better there.
So it’s a medium sized project for a small team to pick up.
Thanks! 
6 Likes
Thank you so much, @carltongibson, for this update! I really appreciate how active the new Steering Council is and how it’s diving into topics and procedures that need revisiting. That said, I do have a few thoughts and questions:
- Would it be possible to involve the current Fellows in these decisions before they are made public? It would be really helpful for us to be part of the conversation ahead of time.
- Is this new process similar to the previous “Design Decision Needed” triage state? If not, how does it differ? If it is, how can we ensure it’s refined so it doesn’t face the same challenges as the predecessor?
- Has the Steering Council thought about implementing a proposal flow for new features, similar to Python’s approach with the “ideas” category in Discourse?
As a Fellow, I feel that a solution along the lines of item 3 might be more beneficial, as it would align better with the current capacity of the Fellows (and still have the same/similar positive outcome, IMHO). The present proposal, as it stands, adds additional workload to us, which is a concern given how stretched we already are with managing reporter frustrations. The reason I mention this is because the Discourse forum seems to have a broader audience and more robust moderation than the Trac system, which has a much heavier burden on the Fellows to maintain without pending or unresolved tickets.
Again, I want to emphasize how much I appreciate the Steering Council’s dedication to refining the contribution process. However, as a Fellow, I would feel much more supported and involved if we could be included in discussions that directly affect our daily work and responsibilities.
Hi Natalia.
Yes, absolutely. This was just a very simple single step that we thought addressable.
It’s not much different from the old Design Decision Needed as far as I can tell. Very similar indeed. I’m not sure what problems you’re referring to, but I’d suggest they can be worked through as part of updating the triage flow documentation.
I really don’t see more work here. Closed with a different choice from the dropdown, and then reopened if needed (same as now) or flag updated to wontfix if not. (That last a new step but glancing at a filter once every so often and updating the ones that need it, not a burden I’d suggest.)
The proposal is no more than a flag for those kind of tickets which have led to so many reports of upset. The wontfix messaging is clearly broken in some way, so the goal is to address that. (As I say, maybe by just updating that messaging.) Input is certainly welcome on how (hence this call) but we didn’t see anything controversial or needing input to get that far. (Of course being Django every idea gets pushback 
)
We certainly want input on other topics, and further aspects of this topic! Indeed we decided to hold off on various points until getting fellow input that is already being planned.
The “ideas” proposal is something that we’ve also talked about, but that’s a bigger change that certainly needs input. I think we have to do something in that space (and more besides probably).
IMO, workflow should still include moving new feature proposals directly to the wontfix state. There is no need to discuss everything.
Indeed there is not! 
A lot of ideas can just be answered with a No.
But there are a lot of tickets opened that are pointed straight to the Forum for discussion. Those being closed as wontfix had led to a lot of people voicing concern over the how they’re handled.
Now maybe — as per the initial post!!! — the solution is to improve the messaging around the wontfix resolution, but a different resolution with better optics doesn’t seem like a big lift.
Or so we thought… — details to be determined — nothing is settled already — if we can find some folks who expressed concern about this issue who want to work on it.
Edit: As per my reply to Natalia — we considered this just one small adjustment, not a solution to all our problems over this process — which is a bigger issue.
3 Likes
Found an older version of the triage process image with design decision needed:
I would prefer that we have a new resolution “requiresdiscussion” as a closed state, rather than an open state (which would imply the discussion belongs in Trac or that contributors submit prs for review).
We should consider how we want to migrate the tickets with an active discussion from “wontfix” to “requiresdiscussion”.
We should think about whether, when a decision is “wontfix”, folks can still reopen the discussion officially on Trac and move it back to “requiresdiscussion”.
TODO: would like to find the discussion to remove “Design Decision Needed”
1 Like
That seems like a fine solution to me, although I’d like to know whether this closed state should be considered (fuzzily) final or not. That is, do we expect that a typically successful new feature proposal that, perhaps unadvisedly, begins as a ticket in trac should be reopened, or should a new ticket be created instead once the decision has been made? I usually think of closed tickets as being in a finalized state, apart from re-opening due to mistakes and misunderstandings.
It does seem like the closed/open distinction is difficult here, without a clear right answer. Do fellows generally consider that something is still on their plate until it is in a closed state?
We currently reopen the “wontfix” tickets after a discussion and they become “Unreviewed” so that they can be reconsidered. If a new ticket was created, this would be closed as a duplicate of the original.
This is the same for “needsinfo” and “worksforme”, the ticket authors add more information for things to be reconsidered and put in the “Unreviewed” state to check whether a triager agrees this can now be accepted (or not).
The closed state is not always final. This is a communication problem and contributes to why folks get upset by “wontfix”
(sorry for the edits)
1 Like
We’ve historically re-opened even very old wontfix tickets when circumstances have changed. That’s worked well, and helps keep discussions focused in fewer places.
That’s what I’d imagined too. Such tickets shouldn’t show up in an Open filter.
IMO: I wouldn’t bother, not on mass. Just work for nothing. Applying a new flag to new tickets, and as one stumbles over an old one would be more than enough I’d say. (It’s not about creating an effort.)
Good question! I’d leave the existing triage flow for old wontfix tickets as it is: you can start a discussion, but personally I wouldn’t encourage changing the resolution just to signal that. (Most likely outcome is it stays as it was, no?)
Thanks!
Edit:
Exactly! That’s the thing to address. The new state is only one possible suggestion.
1 Like
I feel like this post might be slightly pedantic, but possibly worth it.
While I understand the desire to discuss the problem itself, my reading was Carlton was asking for a small group of people to put their hands up to form a small team, go do the work and come back with a solution (or solutions)?
To be clear I’m not trying to invalidate anyone’s contribution to this thread so far, but want to ensure we channel the energy in the right direction. Also if I have read the room wrong let me know! 
2 Likes
There was some of that @nanorepublica 
(But no reason why that organising and thinking can’t be here on this thread too 
)
1 Like
Just want to chime in and this is 100% how I have currently interpreted the wontfix status.
It’s a bit unclear to me when things can be revisited, by whom, where, and how (because I of course don’t want to bother the busy maintainers! …but at the moment I don’t want to raise a ticket until I’m mostly sure it will be accepted, since if good ideas were to get stuck in wontfix and also block vaguely similar requests that would be bad for the future). There are a lot of decade-old wontfix tickets for example.
2 Likes
