Hypha OSS's repo issues quarterly(ish) triage/rebasing/grooming

Hey folks,

As stated in Maintainers calls in late Feb '22 and early Mar '22 the quarterly rebasing/grooming/triage of issues in the Hypha OSS repo is due (well overdue technically!)

So I’ve created a new ‘stream’ in Zulip chat here where I’ll post conversation topics/updates: Zulip

I’ll also be doing the rebasing/grooming/triage of issues in google meet video room that act as ‘drop ins’ for anyone if they want to drop in and participate or see how it’s going for however long they want to.
Here: https://meet.google.com/yzr-cofp-kyx

On these days a times (GMT UK time):
April 6th 10.00 - 12.00
April 6th 13.00 - 14.00

April 7th 10.00 - 13.00

April 8th 10.00 - 13.00

I’ll also be posting ‘round ups’ of issues gone through in comments on this forum post as I go (e.g. numbers of issues covered, key actions, themes etc.) or edits to this main body of this post.

Rebasing/grooming/triage in an OSS project should (ideally) be a collective/collaborative affair and in my experience benefits from broad knowledge, context and understanding as issues are ‘gone through’, closed (with comments), updated, given better current context or similar and merging similar issues or collecting like issues in METAS/EPICS.
Given that the issues in the Hypha OSS repo are intended to meet the needs of both individual adopters and collectively adopters needs.
This does make rebasing an effort to understand the state of the repo from multiple adopter perspectives including adopters that may be future adopters.

Also remember, closing an issue or PR or similar doesn’t make is disappear forever, it can always be ‘reopened’.

I don’t expect i’ll get through everything in great detail during this time but it’ll be a start.

Historical Context

Y’all can find context of where this topic has originated from here: GitBook

and my follow up proposal here: 3 proposals for adopter and maintainer input: Open Roadmap, voting / 'wish list' and Quarterly Milestone Rebase process

Just curious: does the term “rebasing” here mean rebasing in the technical sense – i.e., actual git rebase operations? Or is it being used in a non-technical sense in this context?

pretty sure non-technical use of the term and means ‘refresh’ in broad strokes. more historical info in docs here: GitBook

1 Like

Wednesday Rebasing update:
Didn’t go fantastically well for me as I’m struggling this week with my chronic illness complications.

Continuing today but will be ‘off the google meet video’ I’m not in a state to be in a prolonged video call room. Progress will be intermittent but will happen. Will be spreading out the effort between when I’m able to look at screens which means rebasing work will continue over the weekend.

Apologies for the slower than hoped progress folks.

Thanks, @eriol. By the way, I just went to that GitBook link and discovered that before it would let me see anything, it wanted me to create an account (with email address, etc).

So before I take another step in that direction, I thought I’d ask you (and @emlini) a high-level question about the role GitBook.com plays in Hypha documentation. Specifically, do people – users or developers – ever need to create an account there just to see content?

Maybe a better way to say it is: I’m unclear on the relationship between GitBook.com and docs.hypha.app. The latter is publicly visible and does not require a login (great). What is GitBook.com for / what role does it play for Hypha docs?

The only mention of it I’ve found is on Contributors - Hypha Docs , but the information there is just one sentence and doesn’t say much (there’s a “TODO” marker next to it, so obviously we knew that the information is incomplete).

Oooomph, very sorry to hear it, @eriol. I hope you feel better soon!

1 Like

Ah you might find some good info here: Quarterly milestone rebase · HyphaApp/hypha Wiki · GitHub

Or I may have simply linked an edit link in gitbook rather than a public link if so :man_facepalming: maybe try this one too: Quarterly Milestone Rebase - Hypha Docs

re. Gitbook I think folks shouldn’t need to create an account to see content but also I’m not familiar with Hypha’s gitbook set up (I used gitbook at Ushahidi but the set up might have been different).
Pardon if you’re already aware of Gitbook generally but I think it’s just supposed to be a more ‘friendly and collaborative’ way of building out docs sites. Me and Emily can (and do) do docs editing on the same page at the same time with the need to push/pull etc.

Though I do recognise and hear that this is less ‘open’ than docs via .md PR’s on the docs repo in that you need to do a login/password so worth Emily + maintainers having a think if this process can be opened up more.

Oh, I wouldn’t want to stand in the way of you and Emily (and anyone else) using a collaboration tool you’ve all agreed on – if GitBook.com is making things easier, go for it! My question was more about whether a contributor has to use GitBook in order to participate, but it sounds like they don’t: they could edit the docs (using whatever editing software they want) and submit PRs on the docs repo, and that would work too.

(I mean, GitHub itself is a proprietary online service that requires an account too, so there’s certainly no philosophical difference here. It’s just that many contributors already have that account, where as GitBook accounts are much more rare. And, in principle, someone could use plain Git and git format-patch to send git-annotated patch files, if they really don’t want to use GitHub. Probably no one will ever do that, but it’s nice to know they could if they really wanted to :-). )

By the way, that second link (to the public docs site) seems like the one – thanks, @eriol!

1 Like

Hey folks,

Here’s an update from the 2 weeks of rebasing/grooming/triage from 6th, 7th, 8th, 11th and 12th of April.

I spent approx 3-4 hours per day grooming issues. You can find them collected into updates in a riseup pad here for (hopefully) more clear digestion: Riseup Pad

rebasing/grooming/triage of issues is by no means ‘done’ - there are still a good amount of issues to comb over in the repo though this is a good start to beginning to understand what is there and standardise issues in some way.

rebasing/grooming/triage will continue to be done by me on an adhoc basis though i’m trying to find a regular time slot per week to continue ‘grooming’.