Engineering Workstream Budget

Workstream Discussion Engineering
1

Please find below a draft engineering workstream budget proposal. Looking for feedback about this. We will hold a community call on Monday or Tuesday next week to have a more interactive discussion, and would appreciate feedback now as well. Thanks.

====================

This proposal is to pay salaries for 12-14 engineers to fulfill the duties of the Engineering Workstream as detailed in the approved proposal which created the workstream: Boardroom Management Portal

https://global.discourse-cdn.com/standard10/uploads/foxcookieco/optimized/1X/8500c3b9e7585040b7373cf53f7eba88ebb48d15_2_624x172.png

Link to budget png: EngineeringWorkstreamBudgetProposed.png - Google Drive

Following precedence from other workstreams, salary includes $30k per year per stream worker for benefits and additional fees incurred with self-employment status. The budget increases in January are due to the fact that some of the core dev members will be paid salaries by ShapeShift, Inc until Dec 31 and become included in this budget beginning Jan 1.

At this time, the Engineering Workstream will not be managing the accounts or charges for any infrastructure and tooling, thus the budget being presented is primarily for salary. Contingency is included to cover unknown costs. Any amount remaining at the end of the budget cycle that is not spent will be sent back to the DAO treasury no later than March 15th.

If the contingency is not needed for other purposes, it is the hope that funds will be used for a workstream “onsite” meeting, where everyone is gathered in the same physical space for a few days of work and fun.

Salaries are designated in $USD, to be paid in FOX on the 1st and 15th of every month. Engineering Workstream Leader will work with the DAO treasury to get funds on a regular basis to cover payroll in a timely manner. Because the budget is denominated in $USD and FOX is a volatile asset, any decreases in the price of FOX will warrant additional transfers of FOX from the DAO to the Engineering Workstream to ensure the workstream has enough FOX to cover its budget.

2

Huge fox props to Josh for putting this together.

I’m in full support of this proposal, as it’s essential to ensure a smooth transition after 31st October.

This workstream will keep centralized infra operating smoothly (current platform and mobile) and continue to develop the open source versions of ShapeShift.

Full disclosure - I will be one of the engineers in the workstream benefiting from this proposal.

3

Thanks for putting this together and for all of the coordination work that went on behind the scenes to agree on salaries 1f64f

I’m in full support of the DAO funding this budget as a strong dev team is vital to our success. I think the salary total seems fair; not too high and not too low.

I’m grateful that the DAO is able to attract 12+ talented and experienced devs to work full-time in this competitive job market, and look forward to seeing the number of community contributors continue to grow.

4

Hi Josh,

Could you break out the salaries a bit more thoroughly in terms of per month, how many engineers are being paid and how much? Is it 12 to start and the hope is to add an additional engineer each subsequent month? The budget that Tyler had a good break out on the Ops workstream budget showing the funds and how they are being used per person/if someone was in that slot already.

Also, Contingency is very vague and isn’t quite disclosed how these funds will be used/allocated/what will happen if not allocated. Could you elaborate more on what these will be used for?

5
  • Overall, I’m hugely supportive of this workstream. It’s obviously super critical to the success of the DAO and completely necessary. I would love to understand specific deliverables for the workstream in order to get an idea of what $714,000 every 4 months promises to deliver.

    Pulling from the previous approved proposal:

    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
  • I would love to understand specifics.

    How many new features? What is regularly?

  • Products developed, how many?
  • Thriving open source community? How?

After reading the proposal linked again, it reads to me that the workstream has a lot to accomplish. In order to make an informed vote, I’d like to understand what is going to be accomplished in the 4 month timeframe.

If these are dumb questions - please excuse my ignorance, I’m not an engineer. Please help me understand why the questions aren’t good, and how to phrase them correctly to understand it.

6

Thanks for all the questions. Below I attempt to address each that I have seen so far.

Salary break down:

I can break down the budget some more. I don’t want to get too specific in a proposal that is voted on, because if changes are needed, I’d prefer to not have to keep coming back for votes, unless of course we would need more funds due to the changes. And I will break it down more for the community call next week, as well as in the next version of the proposal.

Questions about the contingency:

it is for unknowns, I can imagine if a community dev winds up being awesome and wants a full-time position, we could hire them full-time. Proposal does state that if any is left over at the end of the term, funds will be returned to the DAO treasury.

How many new features? What is regularly?

As far as what new features will be developed, the only way to answer that with integrity is to say “I don’t know”. There will be a roadmap meeting with the community in coming weeks. I can’t be sure what the development priority will be starting Nov 1, when this budget starts. But I guess I can add that features developed will be from the roadmap as determined by Product.

Good question “what is regularly” - I think that was a bad statement on my part. It’s a hard metric to define, because part of it depends on how difficult new features are to implement. One way to measure this is by how often new code is committed into the codebase. Or perhaps better stated is how often new code is committed could serve as a proxy for measuring “regularity” of new feature development. That should be happening pretty much every work day, with few exceptions.

Products developed - how many.

That goal was meant to mean that as we add new features to our products, they will be built such that tools like Pendo can be integrated so that other workstreams can effectively accomplish their goals. So asking “how many” here does not make sense for the context of this goal. Does that make sense now that I’ve provided more details on this particular goal?

Thriving open source community? How?

I think the question is how is that measured. I would measure that by number of commits merged into the codebase from community developers. That should increase over time, up to a point. How we make that happen is a great question, and one that we in the engineering workstream are asking all the time.

7

also provided more information in the initial proposal to establish the Engineering workstream as well asa the v2 Open Source kickoff call.