Given the high number of open TW5 tickets on GitHub. Who should close them?
By convention, the submitter of the issue, feature, or pull request should be responsible for closing the issue. Be it resolved, or not. Some submitted by a new user struggling with the mechanics of TW5, or requests years ago which have totally, or partially, long since been addressed.
So, how do we get the issues and PR requests under control?
The activity of closing a ticket requires no coding or technical skills. Is a matter of contacting the submitter - determine if issue is still pertinent, have them close it, or advise will be closed unless they refresh comments on the ticket.
@jeremyruston is setting up TiddlyWiki as an organization, which would allow permissions for individuals to close dated, stale, or āwill not fixā issues and PR requests. Hopefully to focus on current issues that need to be addressed.
Given TiddlyWiki is becoming a GitHub āorganizationā, what are the organizational ideas about dealing with getting issue and pull requests under control?
My own preference would be to close tickets unless they are actionable, and therefore to keep the number of open tickets more reasonable. But over the years Iāve found that contributors often feel strongly that the tickets for rejected ideas should be kept open so that they donāt get lost.
Thereās a clear tension between the desire to manage the issues list as an actionable todo list vs. the desire to manage it as an active archive of everything that has ever been said.
I couldnāt find it but there was a discussion on GitHub that I kicked off suggesting that we bulk close all the open issues, to give us a chance to start again. I think @pmario was involved in the discussion and may remember it.
Also, I made a burndown chart earlier this year to explore the problem:
I think Talk.TiddlyWiki suits most community members. Be it a newbie, a long time user or developers.
I think it has proven itās value and usability. Talk is 1 year old now and we have ~200 new threads per month, with ~1500 up to 2000 posts per month and 80000++ human page views per month.
add 2)
Now that we have 1) and 3) I think we can ālabelā all issues and āmoveā many non actionables into the GitHub Discussions section. Or we give them a ālow priorityā label. Or we close them.
add 3)
GitHub Discussions donāt have very much traffic. Itās about 1 1/2 years old and we have ~300 threads there. I think is mainly used by āplugin creatorsā and ādevelopersā to reach consensus and define something actionable, that can then be āconvertedā into issues.
..Speaking for myself, I donāt think I will never, ever have the time or motivation for a systematic review of the open issues.
From time to time I am motivated to review them. .. I would be willing to label them all. to enable fast sorting
I think that all GitHub issues should be labelled, so they can stay open for a long time, without āstrong feelingsā. Atm we do have some main labels
bug
improvement
newfeature
documentation
discussion
refactor
needs-work
wontfix
I have to say that I exclusively use the GitHub Web UI and I think labels would improve the usability of the issues quite a bit.
Sure, those labels would be opinionated but changing them back is simple. ā¦ My opinions are:
bug
These issues are critical and we should try hard to keep that number down
Itās possible to replicate them
If they canāt be replicated they get the label: not-replicable and are closed
Some issues are really old and may be fixed already
improvement
Is no bug, but an inconvenience.
Is actionable
optional new labels: easy, medium or hard
which specifies the complexity how āhardā it is to fix them. This should be a way for new contributors to get their hands ādirtyā
newfeature
Is actionable
Is a feature request. No problem if they stay open for a long time
optional easy, medium or hard
If there is a plugin, which provides this function itās labelled plugin and itās closed
documentation
It should be possible for users to fix it with the docs-pr-maker
optional label easy or medium
discussion
Is not actionable and therefore needs more discussion
They should be moved to the discussions area until they are actionable
Once they are actionable they can be labelled newfeature or improvement
refactor
Is a label which should only be used by core developers, because it needs low level refactoring of core code
Refactoring may create backwards incompatibilities
needs-work
Is mainly used for pull requests (PRs), that canāt be merged because no consensus is reached yet
wontfix
Is an issue where consensus was reached, that it wonāt be changed.
Thanks @pmariothat is indeed the discussion I was thinking of.
I think the crux is our criteria for closing issues. The germane part of one of my comments is:
The core of our issue here is that I am not sure that having lots of issues like that with the āopenā status is of much value to the project. The idea youāre proposing is a good one, and might be worth pursuing, but this feels like the wrong place for it. Why would we want 100s of open issues that describe good ideas that might be worth pursuing? Theyāre very hard to spot amongst the 100s of ideas that arenāt worth pursuing. Arguably, the really important open issues are the bugs that remain unfixed, but again itās very hard to spot them if we use the āopenā status as a sort of long term wishlist of features that people would like to see.
To me āopenā should mean under active discussion, and it seems reasonable to follow other projects in automatically closing open issues after a period of inactivity to give us some hope of being able to see the wood for the trees.
One of the problems is the way that GitHub highlights the number of open issues, and a high number is interpreted as bad. That means that we have little choice but to optimise for closing issues if we want the project to look like it is well maintained.
Thatās right. .. sadly itās the way it is at the moment. IMO if they are properly labelled it isnāt that big of a problem anymore.
As I wrote in my proposal. Iād be willing to label all and every issue and I may also add labels to existing discussions with eg: ādocumentationā, ānewfeatureā ā¦ if needed.
Then the only label we really have to be scared of is:bug
We do have 8 labelled and open bugs atm. Which isnāt that bad. What really bothers me about them is, that they are from 2015 and havenāt been addressed.
Every couple of months I spend some time going through the open issues to identify those that can be closed or need follow up, as well as to identify low hanging fruit in terms of meeting user needs. This process however is far from efficient and most of my time and energy gets spent just wading through the huge uncategorized list of issues, leaving little to no time to actually work on anything.
There is a secondary issue where some of the tickets are long sprawling discussions that are simply too time consuming to read and follow to understand what the next steps should be.
From my perspective the real problem with the large number of uncategorized issues is that they make it difficult to triage issues and prioritize oneās contributions. I really wish we could close all issues that are not actionable. If they contain useful discussion they can be converted to discussions. After all, closed issues are still accessible, searchable and can be re-opened if need be. The longstanding issues just sitting there donāt get any more attention now than they would if they were closed or turned into discussions, but they do detract attention from the more actionable issues.
Since Iām not involved in this it is arrogant of me to say much. But, it seems to me, much of that vast ābacklogā is ādead wood.ā Wipe it down?
TBH I think a clean plate that deals with issues within say, 2 months???, is the way to go. Having a heavy history that is not solved helps no one!
???