Who should close issues and pull-requests (tickets) submitted to GitHub?

Developers
#1

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?

#2

Hi @poc2go there are some challenges here.

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:

1 Like
#4

The last time we had this discussion, we didn’t have the possibilities we have today

  1. This talk.tiddlywiki.org discussion group.
  2. GitHub Issues
  3. GitHub Discussions

add 1)

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.

At Is it possible to transfer dicussions from Issues to here? · Discussion #5301 · Jermolene/TiddlyWiki5 · GitHub @jeremyruston wrote

…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.

I think here’s the GitHub discussion Jeremy mentioned: Is it possible to transfer dicussions from Issues to here? · Discussion #5301 · Jermolene/TiddlyWiki5 · GitHub

2 Likes
#5

Thanks @pmario that 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.

#6

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.

The first in the list is: Filtered transclusion parsing is too greedy bug and it’s still valid :confused:

#7

In the context of this thread I think that a very relevant observation … the volume of stuff is one thing. Bugs is another.

Just as an observer I’d say that dealing with the old (putative) bugs first would be a good idea. :slight_smile: ???

Best, TT

1 Like
#8

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.

#9

Right.

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!

Just comments
TT