There are a lot of open tickets, I might say an overwhelming amount for someone looking to help out with contributions. I’m going to propose a small to medium sized change here.
There are a couple of hundred tickets open that I’d judge if I opened fresh today I would be politely steered to the new features board and the ticked closed with needsnewfeatureprocess
It wouldn’t be unheard of that a new contributor takes one of these and dives into working on them, not realising that there may not actually be community support and their contribution is not taken on with open arms, leaving to a less than stellar first experience contributing that may be the end of their interactions with the project.
We could solve this by following what @jacobtylerwalls did a few years back when he
did [a] sweep through most of the open PRs and either check a missing “Has Patch” or “Patch Needs Improvement” flag, or leaving a comment for the author if I wasn’t sure, asking them to choose the best course of action.
I could take all tickets that are marked as new feature that haven’t had any movement in more than say 18 months and update them with a similar message to a new issue.
This new feature request has been open for some time without reaching the implementation stage. Since it was opened, Django has introduced a new feature tracker to give features a clearer path to implementation.
If you would like to see this feature progressed I advise you to raise an issue there for the community to discuss. I’ll close the ticket for now, but it can be reopened when the community has an implementation plan. For more information, please refer to the documented guidelines for requesting features.
I’m partly sympathetic to this, but I do wince at the prospect of having to repeat discussions that have already reached consensus.
We pretty thoroughly link to Sarah Boyce’s “vulture method” advice for finding approachable tickets, and IIRC one of the points is “don’t pick something with loads of comments” for your first ticket. I’m assuming most unimplemented 10+ year old tickets are either drowning in comments, or about something niche like SELinux.
Thanks for reminding me that it might be a good time for another PR sweep.
To me, that sounds like a negative outcome. So few users of Django contribute to it or are even aware of its mechanisms for tracking development that I don’t think we can extrapolate that “nobody wants this” from ticket age. (Don’t get me wrong, I agree with the idea that times change and that old ideas should be re-evaluated in light of recent changes in the industry.)
It’s negative if we are saying closing means we don’t think this is a good idea or doesn’t have support. But if we are adding an explicit message about the need for new feature we are helping people who discover it. The ticket is still there. I’m arguing that is not negative.
That ticket might need a DEP, but I don’t think it needs the new features process. It’s pretty much a unanimous opinion that we need it, and the patterns have been proven in third-party packages. Doing the extra paperwork wouldn’t hurt, I guess, but I think this supports my point that we don’t need to rehash every discussion.
There are a couple of hundred tickets open that I’d judge if I opened fresh today I would be politely steered to the new features board and the ticked closed with needsnewfeatureprocess
In the very early days of Django, I feel some tickets were accepted based of the triager going “good idea” and there may have been minimal discussion and I agree that today those tickets may go to the new features board and might not get that much traction.
If you would like to see this feature progressed I advise you to raise an issue there for the community to discuss. I’ll close the ticket for now, but it can be reopened when the community has an implementation plan. For more information, please refer to the documented guidelines for requesting features.
I think this might be a little too strong. There will be:
tickets that had good discussion and had a consensus to get done, but no one has approached this as folks don’t know how to do it
tickets that get asked for multiple times, those tickets are closed as duplicates but the original ticket is not updated (so the ticket may not look popular, but it is quite popular)
tickets were the author is no longer around in the community (some community members have even passed on)
I feel that there may be some components where this approach would be more successful than others. For example, there is a general consensus that the admin is already quite feature rich/complete. We may agree that we want to challenge old accepted admin new feature tickets. If we were to do this, I feel:
Unless there’s a net positive from Trac being cleaner (whatever that means) I’d generally avoid this kind of bulk update sweep-through. It’s work that could be put elsewhere.
Historically we’ve tried to resolve issues one by one, and (IIRC) we explicitly said we weren’t going to apply the new features work flow on mass to the existing tickets when we adopted the new system.
So, unless we have (something like) three fellows saying ≈ “We want to do this” then I’d lean to -1 on the standing default to the status quo.
A part of me thinks it’s a good idea: I’m not anti it per se — and on one of my own projects I might be more aggressive — but it would be a change in tone for Django. (That may not be a bad thing but, I’d like to see significant support from stakeholders for it before leaning that way.)
Another thing that’s at play is that we’re still sorting out how to manage the new features board. How do we highlight ideas, advocate for some and bring old ones to the surface. Not to mention, it’s still not super clear how we go from “Yup, let’s do this” to “I’d like to do this” to acceptable chunks.
Yup. For now, I agree with our prior decision to keep the old accepted tickets as is, and let the reviewers / Fellows judge if something needs to come back for more discussion.
If we can get the new features pipeline into a more efficient shape, we can revisit that. Though I suspect it may be a 7.x Steering Council endeavor.
