Proposing Engineering Workstream

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?

  1. 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.

  2. 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.

  3. Fix high impact bugs
  4. Assist community developers on-boarding onto the application stack, conduct community developer PR reviews, and assist community developers with design decisions as needed
  5. Make production-running legacy code bases either open source or deprecated
  6. New feature work
  7. Any other work that is deemed necessary or beneficial to the product suite and DAO, as determined by the workstream
  8. 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.

When the time comes, I plan to humbly throw my hat in the ring to take on the Engineering Workstream leader role. For those of you that don’t know me, I’m the current Director of Engineering at Centralized ShapeShift. Here is my linkedIn profile: https://www.linkedin.com/in/joshuaforman/

Happy to discuss / debate my qualifications for this role at the appropriate time. I will not crowd this reply with this now.

At this time, I am looking for feedback on the proposal to create the workstream so it can go to vote. I think it’s important that this be done in a timely fashion, so that we take concrete steps for current engineers to have a future way to contribute to the DAO and get paid to do so. A future proposal will make a request to fund a group of engineers into this workstream.

This is clearly a needed workstream and I definitely support you as the initial leader of this if you are throwing your hat into the ring .

I appreciate you laying out what some of the responsibilities and regular meetings of the workstream will look like and I assume this will evolve over time. I do think starting public calls with the community focused on engineering, brining in community devs etc (even ahead of things actually being open sourced or just beginning to) are really important and I would hope to see that start in the next few weeks if possible, I think that would be a great way to demonstrate your capabilities as workstream leader even ahead of being elected as such.

I also think visibility into how the product/engineering workstreams will work together and collaborate is also really important, making sure those workstreams are working together on process and how features and work get prioritized over time (and making that process as transparent as possible to the community so they can be involved).

In regards to some of the other needs you mention, I think the operations workstream that has suggested (and thrown his hat into the ring to lead up) would be the right one to lead up the manual regression testing and work hand in hand with the engineering workstream on that front (he suggested in his proposal for an operations workstream that as one of their responsibilities and it makes sense given how centralized ShapeShift has operated in the past).

Overall I am very supportive of this and look forward to seeing the engineering workstream form and move forward!

After these comments and some real time chats, I am now planning to add my assignment as the workstream leader to the proposal to create the workstream when it goes to vote. Thanks everyone for the support. Exciting times ahead!

I support you Josh as workstream leader. Thank you for moving this forward.

Thank you for advancing this and getting it passed