Development Committee Charter and Q1 Funding Proposal

Generally I consider there to be an ‘inverse premium’ on part time work (e.g. $150/hr extrapolates to $312k a year for ‘full time work’ but given that, generally, more time focused on one thing = more efficiency = more value, so full time work is more valuable than part time work). In my own consulting practice (on the hiring side, not the sales side) I always personally used a model of half time = 1/3rd pay, quarter time = 1/6th pay, so in my head i’m looking at those salaries as equivalent to a $500k/yr full time engineer. That’s totally within the realm of reason for top talent, but as i said, that makes expectations high. Of course this economic model is my own, so I’m not putting it forth as a source of truth, I’m just adding some context for why I consider those salaries high. Not challenging it.

Looking at the meeting notes, I would still like to know what outcomes we’re expecting from the mentorship program. It looks like it’s going to be a one-on-one, or perhaps one mentor to two-three apprentices type of structure. Are we just trying to attract people simply interested in learning and helping them out? In my opinion, we would be vastly overpaying for this kind of service. Are we going to accept apprentices that have put forth proposals for dapps (perhaps prioritizing grant projects: GitHub - scrtlabs/Grants: Repository for grant proposal submissions) and providing them assistance through mentors to help execute those proposals?

I think the community code repository is a good idea. Can we expect to see a roadmap for the community code repository, a way for the community to provide input on that roadmap, and perhaps bounties for contributors outside of the committee?

Regarding things like anti-patterns, can we expect to see some documentation created and maintained that outline best practices for contract design, anti-patterns to avoid, common security holes, etc? And if so, will we have a strategy for keeping that documentation up to date?

2 Likes

You’re absolutely correct, we should be prioritizing apprentices who show real promise in being able to contribute value to the network. Working with dApps developers who have ecosystem grants in progress is an excellent way to insure mentors are positioned optimally.

My thoughts are mentors would start with 1 apprentice. Leads will be evaluating performance of the program weekly and we could consider offering more apprentices per lead if it feels like there is some need for that.

re: community code repositories. Yes, there may be some overlap with members in the committee becoming the core contributors of the code repositories (especially at these early stages) but the goal is actually the opposite. We would hope that the code repositories and their respective bounties will attract outside talent.

re: things like anti-patterns. The most effective way to insure repositories are meeting these criteria are through thorough PR reviews. The dev committee leads will be the owners of the community code repositories and will comment on what areas of the submission need more work or do not meet certain criteria. Since there is another team currently working on developer documentation, I imagine they have will have many or all of these points covered. The dev committee will certainly help that team identify any missing best practices, anti-patterns, or security risks to maintain within their documentation.

Very much appreciate the expanded view on your mental model for hiring rates. It’s quite helpful.

2 Likes

I see, it’s the education committee that is handling developer documentation maintenance as Laura said, right? I forsee issues whenever responsibility for closely adjacent tasks lies with separate parties. It’s not insurmountable, but lots of documentation updates emerge from live experience - e.g. catching a bug in a review or during testing, identifying a problem that wasn’t covered in a guide, implementing a workaround for a problem with an outdated support library, etc. If it’s not expected that the development committee is responsible for ensuring the necessary updates are made, then it’s likely that the documentation will become out of sync with reality, or just have significant gaps that result in the same questions being asked multiple times, as is the case now.

As you said though, the dev committee will help that team make sure that the documents are being updated accordingly, but I just forsee pain points is all. I generally consider developer documentation to be well within the purview of developers which is why I am belaboring the point a bit, and the developer onboarding experience is particularly miserable on Secret Network due in part to issues with documentation :stuck_out_tongue: but as long as there’s attention to the documentation hygiene I will personally be satisfied.

Just one more point of discussion re: mentorship - can we expect to see selection criteria for apprentices and specific goals for the mentorship program soon-ish? I think it would be good for people to see what exactly the committee will try to deliver through the mentorship program before we are able to make an informed vote.

2 Likes

Yes, I’ll update the Developer Committee Charter with more detailed specifics to the mentorship program some of which has been discussed here.

2 Likes

I support the committee charter. Looking forward to seeing it come together!

1 Like

I like the direction this committee is going, especially with regards to mentorship. This is the type of thing I was fighting for in the Support proposal. Thank you!

One suggestion - can you please update the top-level post with the changes?

2 Likes

Looks like the forum won’t let me edit after too much passed time. Below is the final proposal reflecting the updated 3 month ask. Note: I’ve increased the anticipated allocation of mentors from 3 to 5 given the updated 3 month timeframe. And of course, any unused budget will carry over.

Q1 Funding Proposal - March. 1st 2022 to May 31st 2022
The Development Committee seeks funding for:

Base Compensation Dev Committee Leads
Gino - $150/hr @ 10hrs/week - 13 weeks + 1 weeks (backpay) = $21,000 USD
Lumi - $150/hr @ 10hrs/week - 13 weeks = $19,500 USD
Xiph - $150/hr @ 10hrs/week - 13 weeks = $19,500 USD

Discretionary Budget

  • Code Repo Micro Bounties - estimating 7 repos at max 500 SCRT per repo = $17,500 USD
  • Mentorship Program - estimating 5 mentors at max 6hrs/week per mentor @ $150/hr = $58,500 USD
  • Secret Talks - Max $100 USD per talk = $1,300 USD

Total:
$137,300 USD

Total with 10% Buffer:
$151,030 USD

Carry Over
Any budget not used in Q1 will carry-over to the next funding period

Note there was a small math mistake submitted earlier. This edit reflects the correct values and here’s a spreadsheet showing the breakdown Secret Network Dev Committee Funding 2022-03-01 to 2022-05-31 - Google Sheets

1 Like

Thank you! I think moving to 3 months is the right path forward as well.

1 Like

Thank you for this great initiative & set up

Personally I think the hourly rates are too high, for not much auditable activities & outcomes, but lead and participation plans.
While it can match with some actual private market business practices, i consider these efforts to be community oriented ones, while they look like individual businesses on top of a community fund.

I am definitely not denying the need for incentives, and i would be pleased to be paid that much for such parallel/partial activities, however i am afraid that model doesn’t benefit to the community contribution spirit. I am surely too altruist, and/or greedy, your call.
I would suggest to start lower and get better rewarded when relevant.

just my feedback

2 Likes

Generally, as dev committee lead I will strive to make sure that every contribution to the committee meets certain standards. If it is code, I will make sure it’s documented, in good working order, and adds value (not complexity) to the community. If meetings, I will ensure that every topic is relevant and produces more chances of new code getting contributed to the community.

Can you explain exactly what’s the scope of a lead in this committee ? It sounds like you’ll review PR & organize the meetings ? What is the need for 3 leads (if it’s code review they could have been mentors from what I can tell?) & how do you plan on allocating work among the 3 ?

165$/hour is ~350$/year, which seems fine for an EM but why would we need 3 if dev / code is not in the lead scope.

I find the leads total $ amount quite high, I would have been fine with 1 lead and 2 as mentors but this sounds a bit stretched. Putting into perspective there are dev projects from grants that got way less than 3 month lead salaries for the current committee structure.

Edit: Since there is only a link to the forum thread on your proposal could you edit the first post with the actual proposal so that people don’t have to scroll down this thread to see it ? How much SCRT is the proposal asking for etc … There should be more info in the proposal description box

3 Likes

I’m sorry. But 150/hr = 350k/year.
We are not getting 150/hr worth of value here.

I would support for a much lower compensation. After one year of doing this, if you show with metrics the value that you have brought, I would welcome an increase in pay that is commensurate with the value that you bring. At this time, with the current reimbursement structure, it’s a hard no from me.

1 Like

If you’re not going to be doing any dev work under those 10 hours as lead then the compensation at a tech level of 150$ is not justified. I also don’t see the value in having 3 leads.

I’ll support 150$/hr for the mentorship section, since I think that’s extremely valuable, not for the lead pay.

3 Likes

Is there really 30 man hours per week worth of work for the lead responsibilities? Copy and pasting from the charter:

Lead Responsibilities include:

  • Maintain a list of active and engaged Committee Members and their contributions.
  • Manage the Committee discretionary budget and appropriate funding amounts to community code repositories that satisfy all AC.
    • Provide a helping hand or listen to the needs of developer(s) with in-progress work in the Committee Code Repositories to ensure best chance of success
  • Help facilitate the connection of committee members with other Secret Network community members.
  • Plan and lead committee meetings with a focus on keeping the members excited about attending because of upcoming guest speakers or other valuable knowledge transfer events.
  • Collaborate with other committees to help satisfy cross-functional needs throughout the community.
4 Likes

Thank you for the presented statement.
As a CIO, I understand the competition for talent is ever increasing.
I appreciate the proposal. The questions which I have are not in objection to the recommendation, yet to raise awareness and contribution.

Is there a business development manager/organized leadership?
Metrics help support focus toward an achievable goal, will the dev(s) have specific measurables which may be incentivized as a cost control and still offer positive commitment to maintain deliverables?
Can metrics be shared with project timelines for informational purposes? (even as an opt-in for those interested).
Establishing stds, checks and balances, documentation, quality controls…all benefit the future of development. Good work overall. If I can contribute additional ideas please feel free to contact me.
Thank you

PJ

3 Likes

I have no issues with the hourly rates proposed here. However, I second the interest in learning more about the thought process behind 3 leads.

For instance, combining the meeting notes and the proposal, this seems to be the current ask:

30 hours of leads / week
9 hours of code repos / week
- $17.5k discretionary / 13 weeks / $150 per hour
30 hours of mentors / week
- $58.5k discretionary / 13 weeks / $150 per hour

Given the combined 39 hours per week of code repos and mentorship, my intuition is that there’s only a need for 1 lead at 10 hours per week.

This would put the ratio of lead to non-lead time at closer to 26% rather than the existing 77%.

I actually have some other questions. Why would mentorship not be under the purview of the education committee? I get the charter of the education committee is more focused on a broader definition of education, but mentorship is pretty textbook education.

Based on other peoples comments here I think I also agree that the $150/hr rate for mentorship is excessive and three leads for the described responsibilities is excessive.

The more I think about it, the more I think mentorship isn’t necessary. We don’t need to train new developers, we need to make the onboarding experience better. There’s no shortage of developers and all things considered, there’s nothing special about becoming a developer on Secret. It’s a Rust-based smart contract platform like any other. The stuff that is specific to Secret that is interesting is solved with a better onboarding experience, including but not limited to better documentation, better tutorials, and better community code repos.

Regarding community code repos, perhaps a better approach is a separate proposal specific to funding the development and maintenance of community code repos, in an ideal world something like OpenZeppelin. Top quality code requires lots of money and focused effort, and I don’t think we’re going to get that quality with bounties, even if the bounties are large.

Regarding making the meetings exciting so people will attend- I don’t actually think this is necessary. Meetings are not inherently valuable. The focus should be on adding value in specific ways, and only then should we have meetings if they’re deemed necessary.

Put another way, for $150k usd over 3 months, we could fund cutting edge defi apps to fill gaps on the network, or we could fund the complete creation of a Secret Network v1 OpenZeppelin, or we could fund a number of other projects that would drive traffic and adoption. Given that these are simple and generally inarguable sources of value, I think there needs to be a convincing argument that this $150k usd would result in a significantly larger amount of value than actual usable products that could be funded with that money.

1 Like

Hi @gino

While I’m not 100% familiar with the boundaries of responsibility between the education and development committee roles, I can easily recognize the sore points you’re targeting and attempting to address with the proposal you’ve outlined. I think targeting DX makes sense, and you’ve done an excellent job coming up with some ways to move forward.

A couple of thoughts:

  1. Documentation, tutorials, and code samples are crucial for adoption. As such, I fully support the notion of funding bounties for code repositories. I’d personally like to see these blessed repositories consolidated in a central location, perhaps under the Secret Foundation Github organization. That way the foundation has the ability to grant permissions. Otherwise, there’s risk of external repositories going stagnant - someone with good intentions develops a repository with some very useful code samples, but due to changing circumstances, doesn’t have the time to keep the code up-to-date, review PRs, or read issues. By having these repos under the Secret Foundation, you could grant someone else appropriate permissions under those circumstances.

  2. I keep thinking about the mentorship idea and of ways to ensure a return of value. As documentation, code samples, and tutorials will be a work-in-progress effort, supplementing this in the midterm is how I see mentorship working well - though probably for what I’m thinking, the tutoring is the term that would probably be most appropriate. Here’s an idea - have a service where someone can post their question and request a live session with one of the tutors. If a tutor is available, they’re connected right away and can share their screen and work with the tutor to get past their hurdle. If a tutor is busy or occupied, they wait in a queue. Tutors could make their availability known to the service so students are aware in advance. You could go further and vet the students before allowing them access to the tutoring service if needed. I think the foundation could actually charge for this service to recover some of the cost too. Anyhow, just a thought, but I know I’m biased as that’s the kind of service I’d personally be willing to pay for, and too, would love to get to the point where I could fulfill the tutor role as well.

  3. I wanted to mention, that aside from what’s outlined in the proposal, I think one of the biggest efforts we can do that would have immediate value is to assure a timely upgrade to CosmWasm, and have a plan to keep development in-sync with the latest version. Both Secret Network and CosmWosm teams would benefit if we could tap into each other’s resources more in terms of documentation, tutorials, and support via Discord. Perhaps some formal collaboration with the team to avoid redundant efforts might make sense as well. Related to this, it would be a shame I think to see code repositories, tutorials to be developed for CosmWasm v0.10 and then see them all go out-of-date when we finish the upgrade to v1.0. So coordinating and aligning these efforts go hand-in-hand.

I’m happy to see all of the movement and progress here. What a great community.

Cheers!

2 Likes

Allow me to address the general concern of a 3 person - 30 man hour / week co-lead structure.

This idea was presented to me by Secret Foundation and I was also skeptical at first. However, after some deeper contemplation it became clear this would be an ideal structure. Lumi, Xiph, and I have truly complementary skillsets that are essential to agile software development.

Lumi will lead in smart contract development, Xiph will lead in frontend expertise, and I in program delivery. Generally speaking, the highest performing teams in software development always include these specializations. As a community that wants to grow and succeed at becoming a top layer 1 chain we should provide our core contributors with a structure that encourages talent to operate where it feels most specialized.

There is more than enough work ahead of us to fill the allotted 30 man-hours. I imagine most large product companies have much larger budgets going to product evangelism than this. Community Code Repositories will exist with the primary goal of attracting outside talent to help grow the ecosystem but Lumi and Xiph will also help to develop repositories that have not been picked up by anyone. Anticipate some overlap among dev leads and CCR builders as we crank up the flywheel.

I believe a lean and agile team that operates as one mind, similar to those seen at top startups and other tech companies, will prove its ability to deliver higher quality content for the community. Decentralization and web3 is more than just running software in a permissionless environment. It’s also about bringing together people with shared passions and allowing them to quickly squad up to create something awesome together.

re: using the money to fund awesome defi apps: The community pool is already setup for this. Any team or individual is welcome to create a pitch. A dev committee is still needed to help grow network momentum and knowledge transfer. The committee’s purpose is to help make the Secret Network a phenomenal place to build for those future teams.

1 Like

Voted no, primarily due to jumping on chain immediately after changing the whole structure, but also because I think the proposed structure is not sufficiently justified.

1 Like

sure, agreed, but you won’t be doing software development for the base lead section and yet you intend to get compensated as if the rate was dev work

1 Like