A few software engineering process suggestions

[michalfita]

Branching

It might be too early for that, @nuta, but I'd suggest you branch develop or development now where all incoming code, both yours and PRed goes in. Then use main branch for released a more thoroughly tested code.

Contribution

In contribution guidelines suggest people as follows:

• In your fork crate branch issue/ID/description-in-kebab-case and pull requests from there (for your own sake)
  • Any developer with direct access to repository should actually follow the branching guideline and PRs for other developer as well (this however may work if you invite more developers to work alongside you)
• Please stick to one way of tagging commits and PR titles; what worked for me well so far is the following format of the title prefix [#99] area: The description - this way the commit history is much more pleasant to view and refer to particular issues looking for reasoning of the past change.

Discord

I hope you don't mind I bring discussion here, but I'm not a big fan of Discord - I may occasionally jump the ship to talk about something. but only if I'm sure the other party is actually present to have a chat. Normally I'm busy with my day to day work.

[nuta]

Thanks for the suggestion 😃

Personally, I don't prefer using a development branch. For simplicity, I'd stick with GItHub flow. I think we'll need to change the branching strategy someday though.

Please stick to one way of tagging commits and PR titles; what worked for me well so far is the following format of the title prefix [#99] area: The description - this way the commit history is much more pleasant to view and refer to particular issues looking for reasoning of the past change.

Sounds good to me except[#99]: it's redundant since GitHub will append (#99) at the end of the commit message.

Regarding the discord, you don't need to be online as it's just an ephemeral chat room. Join whenever you want to talk a bit about Kerla. GitHub will still be used for discussions.

[michalfita]

Sticking to the model where you push directly to main is fragile - good example recently broken main.

GH will append (#99) when the PR is squashed, but it's good practice to maintain clarity in repositories, even participating forks. Then titles of PRs help to see what precisely they fix.

[nuta]

Sticking to the model where you push directly to main is fragile - good example recently broken main.

Maybe its' a good time for me to stop pushing commits into main directly. How about adding a branch protection rule to ensure all commits pass CI tests instead?

GH will append (#99) when the PR is squashed, but it's good practice to maintain clarity in repositories, even participating forks. Then titles of PRs help to see what precisely they fix.

Adding multiple references in a commit title doesn't sound helpful to me. How about recommending adding a link to the corresponding issue in the commit log?

[michalfita]

Maybe its' a good time for me to stop pushing commits into main directly.

I believe so.

How about recommending adding a link to the corresponding issue in the commit log?

Yes. On GitHub the ID is enough - all three: issues, pull requests and discussions share the same pool of IDs. I from beginning thought about issues; sorry for being unclear about it.

[nuta]

Enabled a branch protection rule to force checking CI results to merge commits into the main branch.

Yes. On GitHub the ID is enough - all three: issues, pull requests and discussions share the same pool of IDs. I from beginning thought about issues; sorry for being unclear about it.

Good point. Adding a corresponding issue URL (not only an ID) to the commit message could be good practice since I often read the commit message from my terminal not on GitHub.com.