Hey everyone! One of the things we want to tackle this year is improving our processes around our open source projects, with the goals of boosting transparency, increasing community participation, and overall making our own jobs easier.
To be consistent with the first goal, we decided to begin by having this very discussion here in the open. Feel free to chime in with your thoughts, and share any existing open source projects you like - so far we’ve been looking at Typescript, Rust, Kubernetes, Rails, Neovim, Crystal, and Nim, among others.
The following is a proposal on how to structure processes from now on.
To make management easier, smaller projects are grouped together by topic. From here on, by project we will refer to one of the following bullet points.
- CLI & Upgrades
- Testing: Test-Env & Test-Helpers
- Front-end: Starter Kits, Network.js, Hot-loader
- GSN: GSN Provider & GSN Helpers
Roles covered by the OpenZeppelin Development team.
- One owner responsible per project
- A second-in-command per project to assist the owner
- One or more support roles to act as first line of support and community managers
The owner is in charge of leading the project, triaging, building the roadmap, reviewing all contributions, releasing, etc. The 2nd-in-command (we need a fun/shorter name for this one!) is the owner to-go person when they need to discuss anything, is who reviews the owner’s contributions by default, and who covers for the owner when they are on vacation.
Support roles answer questions, tag issues, and create new ones (based on community input), working across multiple projects. When on vacation, the owners handle these tasks.
Planning & iterations
Every 6 months, the entire team gathers to define high-level goals for the semester, and compile them into a single public document. As an example, where some items correspond to our current period, and others are made up:
Improve cohesion among our tools
We have many tools today that act as building blocks for creating apps: contracts, CLI, testing libraries, etc. However, it is not immediately clear how to easily combine them all into a single project. We should strive to build a cohesive platform by ensuring all our tools play together nicely with each other, making it easy to adopt a new one while using others.
Build comprehensive platform
Our contracts and CLI projects cover for many use-cases of smart contract developer, but not all. Build the appropriate pieces to ensure that a smart contract project can be fully developed within the OpenZeppelin set of tools, or we have a good project to recommend to our users to cover for those missing needs.
Cater for DeFi projects
DeFi is taking the Ethereum scene by storm. DeFi is possibly the vertical with the largest number of active users today. We should gain a better understanding of the problems that DeFi projects go through, and focus our tools on solving the them.
Given that all our core devs work on Linux or Mac, we sometimes fail to properly support Windows users. We should add Windows to our CI process, and ensure that all our tools work in Windows as well as in other platforms.
Every iteration (taking a page from Basecamp) all project owners gather to plan for the upcoming period. Each owner is responsible for writing the public 6-week roadmap for their own project, syncing with the other owners. The roadmap is built and prioritized according to:
- The 6-month goals: Each individual project efforts should be aligned with the overarching goals of the open source platform.
- Bug backlog: While it is never exciting to fix bugs, it’s critical to maintain a high quality for our projects. Each project owner should keep their bug count low, and prioritized based on the usage and severity of each issue.
- Internal feedback: We are developers ourselves, and are constantly using tools for developing our projects. Our own experiences should be a driver for the backlog as well. This applies to all technical teams at OpenZeppelin - both development and research.
- Audits feedback: The OpenZeppelin research and security team has a unique view of the needs of the industry in terms of security through their audits.
- Partners feedback & requests: Any feedback or requests that derive from our work with technical or business partners.
- Community general feedback: All comments and general feedback from our community and the Ethereum community at large should be taken into account. Our community manager is the to-go person to supply this information, and we can also leverage information from other projects.
- Github issues: All community requests should be channeled to github issues, where we also track how many users are interested in a particular feature.
- User interviews: We can reach out to both our open source users and our audits clients for help in better understanding their problems in personal interviews. These should help not only prioritize but also design the features in the roadmap.
Once the roadmap is defined, everyone sets out to work. New bugfixes or minor enhancements can be included in the 6-week iteration if needed. Each project is encouraged to set a housekeeping day (eg Fridays). The entire team should also gather on a weekly basis for check-ins. An example roadmap item, for the testing project:
New test-environment project
While it’s possible to compile, deploy, upgrade, and interact with our CLI, it is not possible to test. While we recommend our users to work with ganache as a local blockchain, using truffle as test runner causes issues regarding configuration, and we have received internal feedback regarding its long set-up time. Aligned with our comprehensive platform goal, we shall develop a new project for running tests, structured as a library, and easy to integrate with our current offering.
After each 6-week iteration, there is a 2-week cooldown period. This time is used for retrospectives, wrap-up, housekeeping, interviewing, and (most importantly) planning for the next 6-week iteration.
All tasks should be handled via public Github issues, using labels, projects, and milestones. Additionally, we should have:
- One kanban github project per project (forgive the redundancy) for tracking work within that project. The flow should be: backlog, next, in-progress, and done.
- A single set of labels for all projects, including
kind(see SDK), and project-specific
topiclabels if needed.
- A set of milestones per project, including the next patch, next minor, and next major (optionally).
- A pinned issue per project covering the 6-week iteration roadmap (see Typescript for an example)
- The global document with 6-month goals, linked from every roadmap (potentially here in the forum, or in a dedicated repository).
- A set of common contributing guides, linked from every repository
contributing.md(either in a dedicated repo, here in the forum, or in the docsite).
Triaging community issues
Support members should catch incoming issues from the community on a daily basis (weekly max), tag them, and:
- Answer questions, escalating if needed
- Ask for further info if needed
- Reproduce bugs
They should also create issues themselves based on input via the forum, twitter, telegram, etc.
Owners should review all new issues in their repos once a week (consider using the housekeeping day for this), review their tags, and triage them:
- Add them to the corresponding milestone and project, if the issue should be included in the current iteration or the next one.
- Tag as
help-neededif it’s an issue they would like to see implemented, but cannot tackle now.
- Tag as
low-priorityif it’s something they’re interested in, but cannot allocate time to neither develop nor review it.
- Close if it’s not something they’re interested in (must feel comfortable saying no)
Handling community contributions
A similar flow applies to new pull requests by the community. These should be reviewed on a weekly basis (2 weeks max) by the owner, who should take the following approach:
- Reply whether the feature applies or not to the project, providing a quick answer to the contributor, and closing if it does not apply
- Reply whether the feature will get reviewed as part of the current milestone, or will be deferred for later - if it applies to the current milestone, try to review it within a week
- Make a first review on architectural and design decisions
- Make follow-up reviews on polishing and code-style
An issue here with
Contracts is that it has a much higher barrier for contribution quality than the other projects for contributions. We should set clear community expectations that reviews for contributions not tagged as
help needed can be significantly delayed.