TiddlyWiki 5 on GitHub has moved

Announcements
#1

Today we moved the TiddlyWiki 5 repository on GitHub from my personal “Jermolene” account to the main “TiddlyWiki” organisation.

This means that https://github.com/Jermolene/TiddlyWiki5 has now moved to https://github.com/TiddlyWiki/TiddlyWiki5.

Users and contributors will not need to do anything special. The old links will still work because there is an automatic redirect in place.

The motivation for the change is that it gives will give us more flexibility and granularity to give permissions for other contributors to be able to help with project administration tasks such as managing issues and pull requests.

10 Likes
#2

Adding a link to the GitHub ticket from 2018 that first proposed this migration:

3 Likes
#3

That’s great. I did that years ago with a repo from my personal account to a project-team one. The transition was quite smooth, and, although it was just a little hard to let go, it is in retrospect a very useful thing to have done. Eventually, I made my personal one a fork of the main one so that I could do PRs from a fork. I’m glad I did this long before it became a 10m downloads-per-week repo! Cheers!

1 Like
#4

@jeremyruston – It seems the Vercel previews are not built anymore?

It seems this commit did not trigger a build. So the old preview is not updated.

#5

Thanks @pmario. Our Vercel previews cannot be restored without payment to Vercel. See #8420

#6

Very cool, hope this will speed up the PR review speed, this might be a bottom neck now.

1 Like
#7

@jeremyruston Would you allow organization members Members · People · TiddlyWiki · GitHub to merge PR?

Recently unmerged PR reached 200+, and from my experience, I can’t get in-time instruction on what I should change to get them merged. And when I get replied, I don’t have time for them. (Working on other passion projects)

At least for me, my open PRs are “ready to merge” on my view. Otherwise I will make them draft. And if some old PR that is abandoned, you can also close them, and let author open them again when they come back. Instead of leaving them in a vague state, opened but untouched for a long time.

#8

Hi @linonetwo

I do recognise that the PR process can be frustrating. The bottleneck isn’t that we don’t have enough people who have permission to click the “merge this PR” button. The bottleneck is that changes to the core have to be very carefully reviewed and tested. I’ve commented before that it typically takes significantly more effort to review and merge a PR than it does to create it in the first place.

Having said that, there are a few simple PRs (such as CLA signatures) that may well benefit from another person having merge permissions.

So, what I am hoping to do first is to appoint other reviewers with permissions to manipulate the labels of PRs and issues. That will help us get the backlog sorted and organised, and going forward we can evolve a process where the reviewing workload is shared.

2 Likes
#9

Putting on my developer’s hat for a moment, are there test scripts that could be written to reduce the effort to merge PRs?

#10

There is a test-edition which will be automatically executed if a pull-request is created.

node tiddlywiki.js edtions/test --build index does als test it from the CLI. That should be done by a dev prior to creating a PR

#11

I think there is still a good deal of scope to automate things. For example, there are discussions in progress about automating more of the PR checks.

@saqimtiaz recently added a GitHub action to check whether the author of PRs is listed in the Contributor License Agreement which saves a very significant amount of friction compared to me doing it manually.

1 Like