Closed macinsight closed 11 months ago
I'm OK with manually merging PRs right now, we don't really have enough activity right now to call for much automation. I think our branching strategy is also fine for now, best to keep it simple. My primary interest is in refactoring the project to be more easily extended and maintained. I'll try and see if I can find the time to explore that soon.
Labeling of PRs and issues is probably a good idea, what did you have in mind? Bugs vs features vs new models is probably something we should start defining better.
Labeling of PRs and issues is probably a good idea, what did you have in mind? Bugs vs features vs new models is probably something we should start defining better.
Basically starting wtih that, then going from there. All easily defineable with workflows. Was testing "create-issue-branch" a bit ago which could be interesting (I don't like having to leave the terminal, lol. GH CLI's ability to comment on issues says hi, btw)
But yeah, to get back to the point with my rambling, using labels to split bugs, features, models, review-requests, release-candidates for the next milestone is a good idea. (Also let me mention the fact that non-collaborators can't assign labels, I request elevation of status, pretty please)
To summarize: Labels for
I think it'd be a good idea to rename the
master
branch into themain
branch to keep up with current GH and code standards.Also, are you interested in introducing a couple GitHub Actions into this repository aimed at enhancing our workflow? An idea I got in mind would be auto-assigning reviewers and the ability to auto-merge when review has passed its checks. And the labelling feature could be interesting. I'll demo something if ya want.