We are calling for contributors and reviewers for SeaQL projects 📢!
The SeaQL userbase has been steadily growing in the past year, and it’s a pleasure for us to have helped individuals and start-ups to build their projects in Rust. However, the volume of questions, issues and pull requests is nearly saturating our core members’ capacity.
But again, thank you everyone for participating in the community!
- Financial Contribution. You can sponsor us on GitHub and those will be used to cover our expenses. As a courtesy, we listen to our sponsors for their needs and use cases, and we also communicate our organizational development from time-to-time.
- Code Contribution. Opening a PR with us is always appreciated! To get started, you can go through our issue trackers and pick one to handle. If you are thinking of developing a substantial feature, start with drafting a "Proposal & Implementation Plan" (PIP).
- Knowledge Contribution. There are various formats of knowledge sharing: tutorial, cookbook, QnA and Discord. You can open PRs to our documentation repositories or publish on your own. We will be happy to list it in our learning resources section. Keep an eye on our GitHub Discussions and Discord and help others where you can!
- Code Review. This is an important process of our engineering. Right now, only 3 of our core members serve as reviewers. Non-core members can also become reviewers and I invite you to become one!
Now, I’d like to outline our review policy: for maturing projects, each PR merged has to be approved by at least two reviewers and one of them must be a core member; self-review allowed. Here are some examples:
- A core member opened a PR, another core member approved ✅
- A core member opened a PR, a reviewer approved ✅
- A reviewer opened a PR, a core member approved ✅
- A reviewer opened a PR, another reviewer approved ⛔
- A contributor opened a PR, 2 core members approved ✅
- A contributor opened a PR, a core member and a reviewer approved ✅
- A contributor opened a PR, 2 reviewers approved ⛔
In a nutshell, at least two pairs of trusted eyes should have gone through each PR.
What are the criteria when reviewing a PR?
The following questions should all be answered yes.
- Implementation, documentation and tests
- Is the implementation easy to follow (have meaningful variable and function names)?
- Is there sufficient document to the API?
- Are there adequate tests covering various cases?
- API design
- Is the API self-documenting so users can understand its use easily?
- Is the API style consistent with our existing API?
- Does the API made reasonable use of the type system to enforce constraints?
- Are the failure paths and error messages clear?
- Are all breaking changes justified and documented?
- Does the feature make sense in computer science terms?
- Does the feature actually work with all our supported backends?
- Are all caveats discussed and eliminated / documented?
- Does it fit with the existing architecture of our codebase?
- Is it not going to create technical debt / maintenance burden?
- Does it not break abstraction?
1, 2 & 3 are fairly objective and factual, however the answers to 4 probably require some discussion and debate. If a consensus cannot be made, @tyt2y3 will make the final verdict.
Who are the current reviewers?
As of today, SeaQL has 3 core members who are also reviewers:
How to become a reviewer?
We are going to invite a few contributors we worked closely with, but you can also volunteer – the requirement is: you have made substantial code contribution to our projects, and has shown familiarity with our engineering practices.
Over time, when you have made significant contribution to our organization, you can also become a core member.