Please find here my proposal to create our Engineering Workstream. Open to feedback from everyone on what you would like to see different / what would make this a better proposal.
Why should people use this workstream? What is it for?
The Engineering Workstream will be used for a couple purposes:
- Fund the hiring of a set of full-time “core developers”. Initially, this will include a set of engineers that are currently full time ShapeShift employees. How many is yet to be determined.
This Core Developer will have the following priorities:
- Maintaining and running of ShapeShift production systems, both legacy and newly built systems. This will include a 24x7 on-call rotation.
- Fix high impact bugs
- Assist community developers on-boarding onto the application stack, conduct community developer PR reviews, and assist community developers with design decisions as needed
- Make production-running legacy code bases either open source or deprecated
- New feature work
- Any other work that is deemed necessary or beneficial to the product suite and DAO, as determined by the workstream
Note that priorities may change, but the intent is to coordinate resources for maximum impact on DAO productivity.
- Funds approved for bounty work may be delegated to this workstream. This will support the coordination of multiple potential dev efforts.
How exactly is this different than the other categories we already have?
There are no other workstreams being considered to hire full time engineers and coordinate the overall development effort.
What is the mission of this workstream?
To support a thriving open source development community and a decentralized infrastructure delivery effort. We are building a quality software product that delights and empowers our users and gives them sovereign protection of their crypto. We do this with decentralized back-end services and a web and mobile front-end.
What are the goals of this workstream?
- Products working as designed, and available for use
- Thriving open source community
- New features added regularly (through both core dev efforts and community dev efforts)
- Products developed to support use of tools for other workstreams to effectively accomplish their goals
- Engineers should have fun
- The priority / balance between each of these goals will change over time and as circumstances require
What metrics can this workstream’s success be measured against?
- Uptime. I am not sure what a realistic SLA target is for an actively-deving open source repository.
- % of time core team spends dev’ing in open source repos vs dev’ing in closed source repos
- count of bug tickets created, count of bug tickets resolved
- Community developer commits
- Discord community developer chat activity
What should topics in this category generally contain?
- Engineering Best Practices
- Software and Infrastructure Architecture
- Open Source Discussions
Do we need this category? Can we merge with another category, or subcategory?
I don’t see a way around having this category.
Dependencies on other Workstreams
Engineering workstream would be more successful with a workstream that was available to conduct manual regression testing until test coverage supplants it. It is expected that the legacy codebase will always need manual regression testing.
Engineering workstream would need detailed product specifications to determine scope of work and to build new features / make changes.
Engineering workstream would benefit from a workstream that handled
Will your workstream hold recurring meetings?
Workstream will hold recurring meetings. It is expected that subgroups in the workstream may have their own recurring meetings as well. And bounty projects may have their own recurring meetings.