For potential users: Are the number of "open issues" and "open pull requests" an issue?

[pmario]

This discussion started at: #3323 (comment)

Where @ght posted:

The reason I commented here in the first place was because IMHO the high number of open issues and PRs is discouraging for potential contributors (at least for me) and I want to help get that number down, ...

I'm with you, but I can only write, what I do with other projects, that I find on github, when I'm new to the project.

TLDR;
I'm very interested, what other users think, that find TiddlyWiki here at github.

---

If I see a new project on github I initially have a view things I check immediately.

1. I check the Releases and the Tags page of the project, to see if there is development going on and if the project is maintained
2. The I look at the commit history to get info about the latest changes / development
3. Then I look at open issues ... To see what is "labelled" as "bug" (open and closed) ... That gives me a feeling about, if bugs are fixed, if reported.
4. I have a look at the open pull requests.. To get a feeling, how long it takes until PRs are merged
5. I check the project landing / About page, to see "what the project is good for"
6. I check the user documentation page
7. I check the developer documentation page

If I would be new to TiddlyWiki I would be OK with 1) and 2) ... But the rest would make me think twice if I would want to engage in the project on the development level.

BUT

With the TiddlyWiki project I'm completely biased, because I basically know "the whole" history of 3) 4) 5) 6) 7) ...

I did create the first issue at 20.Jan.2012 and some others .. So I know how the project works ;)

---

But anyway, I'm very interested, what other users think, that find TiddlyWiki here at github.

[Technetium1]

I don't expect people experienced with this platform will have difficulty seeing that there's active development.

[linonetwo]

Some of issues are question and ideas, At least we have Discussion and talk forum now, there will be less this kind of issue I think.

[amreus]

Some of issues are question and ideas, At least we have Discussion and talk forum now, there will be less this kind of issue I think.

I think you are right, but with over 900 issues there is a perception that nothing is being fixed. The fact is only about 125 issues are tagged "BUG" - the rest are presumably questions and ideas. Maybe they should be migrated to discussions, and new issues curated to actual bugs. But I know no one including myself has much time for these housekeeping tasks.

I know work is being done on a daily basis because I try to follow development. But I'm not aware that there is any publicly stated goal. As an example, Cascades were introduced in a recent version. I still don't know why they were needed, how they benefit users, nor how to actually use them. It came from left field as far as I'm concerned. With so many issues there doesn't appear to be any end goal or direction to development.

[Jermolene]

I know work is being done on a daily basis because I try to follow development. But I'm not aware that there is any publicly stated goal. As an example, Cascades were introduced in a recent version. I still don't know why they were needed, how they benefit users, nor how to actually use them. It came from left field as far as I'm concerned. With so many issues there doesn't appear to be any end goal or direction to development.

I do recognise that we need to do a better job of communicating the development goals of the project.

Cascades were introduced to make it possible to display tiddlers with a completely custom view template, without having to overwrite any of the core templates. They have turned out to be a flexible mechanism that we can reuse in several places with the same problem, and with the same benefit: to allow deeper customisations to be made without requiring core tiddlers to be overridden.

The current broad mission of the low level core development is to permit more functionality to be developed in wikitext, without needing JavaScript knowledge. The work in #6666 is a prime example of that.

[amreus]

It seems like there has been an increase in issues since the announcement that v5.2.3 is coming. I understand people wanting to address issues that are annoying or even hindering their work. But maybe a standing requirement for a release is that the total number of issues must be reduced? It might encourage review and resolution of old issues. Just an observation, I could be wrong about the issue count since I didn't note it at the time.

[pmario]

There is always more activity if a release is coming. ... And there have been some more documentation issues than normal lately.

[amreus]

Yes it's logical and perhaps even expected. I was just trying to point out there may be a connection between an increasing number of issues and not having a more clear or narrow focus for the release that I am aware of.

Yet I wouldn't want to discourage anyone opening issues either, so I can see both ways.

[joshuafontany]

I have been thinking about this thread in the context of moving the repository to the Tiddkywiki org account. Ideally we would leave all the existing issues here in @Jermolene/Tiddlywiki5, then triage through them & only bring actionable items to the new repo. I would also suggest having a prominent link to talk.tiddlywiki.org & encourage that as the space to discuss issues/ideas/bugs before opening a formal ticket on GitHub in the new repo.

[pmario]

As I wrote at Talk, .. I'd be willing to "label" all issues, to make them more approachable.

The important ones are "bug" and there should be view of them. I think the number isn't critical anymore, if they are all labelled properly

[Jermolene]

Hi @joshuafontany @pmario GitHub supports transferring repositories between organisations; all associated issues, PRs, wiki pages etc. are transferred along with the code. The benefit of moving the issues is that then it will be possible to give others in the community the necessary permissions to help with processing them (eg @pmario's offer to add labels to the open issues).

https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository

[EvidentlyCube]

I've been poking around old Pull Requests today and I realized one thing. While for a potential user the number of issues or PRs may not be a deterrent, it certainly can be a deterrent for contributors. Every time I think about reporting a bug or submitting a PR I ask myself "Will it gain enough traction to be merged or will it be one of the other 150 PRs that stay there forever?". And I've decided to do neither a few times.

I don't really have a good solution here, but I don't think keeping PRs and issues that are 1 year old or older is a good solution, unless they're still active or require some very long-term discussion/development.

[linonetwo]

Sometimes we just go writing other project or plugins. Maybe because it is unclear how to finish that PR. We will find energy to finish the PR if someone give a clear direction.

[EvidentlyCube]

Now it makes me wonder how often in happened in TW history that a year old PR was merged... I'll make a separate reply in this discussion with my findings.

[pmario]

I don't really have a good solution here, but I don't think keeping PRs and issues that are 1 year old or older is a good solution, unless they're still active or require some very long-term discussion/development.

There are some really old open issues, that still contain very good suggestions. The problem is that nobody had the time or energy to implement them.

As I did suggest somewhere else, I would be willing to give every open issue a label, which would make it much easier to handle them. The only label the is critical is "bug" the rest can be dealt with or not.

[EvidentlyCube]

There are some really old open issues, that still contain very good suggestions. The problem is that nobody had the time or energy to implement them.

But unless the list of very good suggestions is somewhere out there is there any value if no one knows about them?

As I did suggest somewhere else, I would be willing to give every open issue a label, which would make it much easier to handle them. The only label the is critical is "bug" the rest can be dealt with or not.

I think that would be a much needed improvement.

[EvidentlyCube]

So I played with Github API a bit. Here are rough amount of time it was between creating and closing (abandoned or merged) PRs:

Merged PRs:
1 day                  1426  44.05%
1 week                  584  18.04%
2 weeks                 127   3.92%
1 month                 100   3.09%
1 quarter               125   3.86%
Half a year              65   2.01%
A year                   32   0.99%
More than a year         23   0.71%

Closed PRs:
1 day                226      6.98%
1 week               169      5.22%
2 weeks               59      1.82%
1 month               41      1.27%
1 quarter             66      2.04%
A year                57      1.76%
Half a year           54      1.67%
More than a year      83      2.56%

Here is a list of all the 55 PRs took half a year or more to merge. I briefly looked through a random selection of these PRs and it seems like almost all of the fit into one of those camps:

• They were done quickly and then merged after a long time without much fussing about - usually missed or forgotten.
• They kept being developed over a long period of time.

A fairly common occurrence is someone bumping a PR that's be ready for merging for a while and @Jermolene apologizing for missing it and doing the merge - I think I see where the bottleneck might be 😉. But @linonetwo is right that it often happens that development is just spread over a long time.

I also took another deeper look at the older open PRs and it's true that there are a lot containing potentially wanted changes that just... stalled for one reason or another.

---

There is certainly a throughput problem here. Everything goes through @Jermolene but there is only so much a single person can do in a day. I don't really have any other conclusions and in hindsight this was probably an obvious one

[linonetwo]

Maybe we can use github project view to manage them, like appflowly does https://github.com/orgs/AppFlowy-IO/projects/5/views/12

[Jermolene]

Maybe we can use github project view to manage them, like appflowly does https://github.com/orgs/AppFlowy-IO/projects/5/views/12

I think that might get easier once we move TW5 to the TiddlyWiki organization, and get finer grained access control.

[EvidentlyCube]

I accidentally stumbled upon this issue: #3313

I know @pmario you participated in that discussion but it was years ago, so just wanted to add it to the conversation as I think the OP made some valid points.