I just experimented with swapping version labels for milestones (here’s the one for 1.1), which have quite a bit more functionality for targeting releases. For example, you can sort the issues associated with a milestone, and so prioritize them; including, I think, to solicit PRs.
This is another newer feature of github we could exploit in time; PR reviews.
Would work well for schema and documentation PRs; much better probably than using standard comments.
I added a review comment to my intext PR here, for example.
Here’s what the reviewing popup looks like:
One problem with multiple repos for evolution, schema, etc.: PR and issue integration on github are most fully realized within a single repo.
So you can close an issue with a PR, for example, but only if the same repo.
Maybe a workaround is when an issue is accepted on evolution, we transfer it to schema?
Yes, probably when we start working on an issue, or when we assign a feature to a release (after the discussion but before the implementation is done).
1 Like
I think we’ve managed to mostly get the project board sorted.
To summarize:
- here’s the “proposal review” project board
- I removed version labels on the accepted issues, and replaced them with milestones
- here’s the evolution (they are scoped to the repo) 1.0.2 milestone
- so I created a minor 1.0.2 release milestone for changes to the
csl-variables.rncfile, in essence; and a 1.1 one for changes elsewhere - on the project board, you can click on labels and milestones to filter the cards
My suggestion is people review to see if this all makes sense.
If it does, I suggest to move the relevant issues from evolution to schema (so that the milestone view will work correctly, though this is a bit hacky), and I can submit some PRs to address them.
Perhaps others can do the same for the documentation components?
Another suggestion is that we think of this process as effectively resolving existing issues.
Maybe we can then figure out how this should work (with project automation, PR review, etc.) going forward to be as easy as possible?
Still unsure: if there’s a 1.1 release, this is where the intext element goes? And we’re doing a new schema release then? So master will then be the “1.1” version?
Do we want to set deadlines on the milestone?
I suggest we do, and that they be fairly soon.
Maybe we should drop the evolution repo, and start all requests at schema?
Thought: maybe this how we can generally think of versioning?
Changes to a, b, c (basically, the strings) are minor point releases, X changes to csl.rnc are moderate (whatever we want to call it) that will not break processors (the intext element), and Y changes are more invasive changes that require processing changes to accommodate.
I can’t follow you here. What do you mean with a, b, c, X and Y?
Sounds good.
I think so, yes.
Soon, like 1.0.2. in Mai/June and 1.1. in September?
In my example, “a” might mean csl-variables.rnc.
“X” and “Y” would categorize different types of changes to csl.rnc.
I created three PRs on the schema repo: one for the new intext element, one for type changes, and the last for variable changes.
This is with the idea in part to figure out how the workflow (in particular review) should work going forward.
Right now, @Rintze_Zelle and @Sebastian_Karcher are the only people that can be set to be reviewers.
I think we want to widen that, maybe with different permissions for different teams. I’ll see if I can figure that out.
OK, I created the schema PR review team on the main org account, then assigned it to schema.
I then sent invites for the team to @Denis_Maier and @bwiernik and added that team as reviewers for the three PRs.
You two should, once you accept, be able to review, but I don’t think you have rights to merge the commits, which rintze and sebastian do.
Can everyone test this please and post here what you think?
Also added frank to the team.
Got it. I got the invitation. I needed to go to the main CSL github profile page for the invite notification to pop up.
I see the review request. This should work well.
Great.
One question I was unsure how to answer is what should be given preference to be assigned to milestones: issues, or PRs potentially linked to issues?
My impulse is the latter, as then the accepted and completed milestones are linked directly to the commits, but I’m not 100% sure.
Worth thinking about though as you test.
Also, teams can have sub-teams.
Got the invitation by mail.
I can see the review request on the pull requests page. But not on the dashboard. Is that supposed to be like that?