I wanted to give everyone the opportunity to voice their opinions without my influence, but…
Anyways, after informing us about his plan, Mr Kaine sent invitations to many community developers to help maintain or administrate the official /zenon-network Github repos.
Congratulations to everyone involved!
Now, we need to come to an agreement on code governance.
We cannot expect anyone to override maintainer consensus, even if they have the power to do so.
Each project has an x of n threshold for code acceptance.
To my knowledge, they all require 2 of n maintainers to approve PRs.
The exception is go-zenon, which requires 3 of n approvals.
Consider the Contributing Guidelines and Code of Conduct.
Developers should hold each other accountable for delivering high quality, functional, valuable improvements. Of course, these goals are subjective. As the subject matter expert in your own domain, I know you’ll do your best to ensure the codebase is maintained well.
I think there should be an expressed desire for a particular change before it’s implemented.
This can come from a community member, any developer, anyone; as long as there seems to be a need, we can probably justify the change.
This expression can be made on any social media, though I would prefer if it’s captured in a Github issue to simplify the tracking of progress.
We can also use Github Project boards.
Some updates will take hours to validate and test. We should try to respect each others’ time; be sure that your code is complete and in working condition before asking others to review it.
We may want to adopt a rule that the person who submits a PR cannot also approve it.
When reviewing a PR, try to submit feedback that is more verbose than ‘lgtm’, though it’s probably acceptable in some circumstances, like one-line PRs or text changes.
Use your best judgment and express yourself if you think something should be different.
I’m of the opinion that PRs should be small in size, easy to digest and test, simple to roll back.
There will still be exceptionally large PRs for more complex initiatives, but I ask that we strive to reduce the burden of validation by making incremental code changes.
It’s much easier to verify ten lines of code than 500 or 5000.
I would like us to disclose test plans with our PRs.
This is to keep ourselves accountable for quality assurance, and to inform others that a certain test scope has been covered. We may need multiple participants to validate a PR before it’s accepted into production.
These are all suggestions for how we should proceed.
Try to see this from the perspective of a developer that just discovered Zenon.
- Who is able to answer their questions?
- What can they work on?
- Where can they find more information?
- How do they contribute?
Some of these questions are out of scope for this topic but we still need to answer them.