Development Committee Charter and Q1 Funding Proposal

Secret Committees
#1

Hello All,

As you may be aware I have been acting as interim dev committee lead for the past 8 weeks. I’ve been leading the dev committee meetings and have gained new relationships with other contributing members while simultaneously working on the first community funded 100% on-chain game for Secret, Secret DreamScape

We officially went to mainnet last night and I finally have some breathing room to put forth a proper dev committee charter and Q1 funding proposal. A revised dev committee charter is available for comment here Development Committee Charter - Google Docs

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

Base Compensation Dev Committee Lead
Gino - $150/hr @ 10hrs/week - 6 remaining weeks in Q1 = $9,000 USD

Discretionary Budget
Code Repo Micro Bounties - I estimate 4 code repos at 100 to 500 SCRT per repo = $12,000 USD
Mentorship Program - max 6hrs/week per mentor. Q1 estimate: 2-3 mentors @ $150/hr = $16,200 USD
Secret Talks - Max $100 USD per talk = $600 USD

Total:
$37,800 USD

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

About Gino and the Proposal
Open source code does not need to mean unfunded code. Too often in my career I’ve seen brilliant open source work that is sparsely documented presumably because the author was not compensated and moved on to other things. Indeed, much of the most widely used open source code today is sponsored by FAANG etc.

Secret needs to move fast with developer onboarding and one of the best ways to do so is compensating developers for some much needed smart contract repositories. I imagine many of the Secret Boxes ideas Laura has put forth could become immediately fundable repositories for example. I could also imagine identifying smaller more manageable repositories that would eventually be leveraged by a person or team who wants to pick up one of the community curated bounty list projects.

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.

I hope the community trusts my ability to manage multiple projects, engage with various talents, and ensure quality contributions are made as has been demonstrated with the fast delivery of Secret DreamScape. I welcome any feedback and discussion before going on-chain with this proposal.

Thank you!

6 Likes
Governance Meeting Notes Mega-Thread
#2

In my opinion, the committee is too focused on collaboration. I don’t think a committee is necessary for developer collaboration, but of course would be a positive aspect and emergent property of any well-run gathering of developers. I think the missions of a developer committee should specifically be a developer advocacy group. For example, the mentorship proposal makes a lot of sense and we should keep that, and expand the “developer support” aspect of the committee since that is a gap within Secret Network that should be filled. Some other examples of responsibilities that the committee could take on:

  • Improving the onboarding experience for developers on Secret Network, and maintaining the onboarding resources as things change
  • Bounties for things like creating and maintaining tutorials and updating documentation
  • Improving communication between developers and the network. This was a pain point I brought up in CosmWasm Upgrade Timeline Question and the responsibility probably lies with the network to solve this, but I think the developer committee is a good place to figure out that solution.
6 Likes
#3

I love your suggestions, sbeem:

  • Improving the onboarding experience for developers on Secret Network, and maintaining the onboarding resources as things change
  • Bounties for things like creating and maintaining tutorials and updating documentation
  • Improving communication between developers and the network. This was a pain point I brought up in CosmWasm Upgrade Timeline Question and the responsibility probably lies with the network to solve this, but I think the developer committee is a good place to figure out that solution.

There’s also an overlap with the Education committee in terms of maintaining the onboarding resources so I think collaboration is going to happen between the Dev committee and others out of necessity. And the Secret University initiative (early stages, and also part of the Education committee) is also involved with developer onboarding, tutorials and documentation.

Developer support – yes, we need that! The SCRT Labs team has put in so much time in the channels helping to troubleshoot and answer questions, but I would like to see a dedicated support team to kick this into high gear. Maybe something like a tiered support where SCRT Labs can get involved if needed and that way they can focus on other priorities for the network.

4 Likes
#4

Yay, Gino! I’m excited to see you take on more of the Dev Committee leadership and thank you for creating the 1st committee charter :raised_hands:.

I think the Community Code Repository (CCR) like the CCBL is a really cool idea because of the reasons you’ve articulated quite well. While the CCBL projects are larger in scope, having smaller CCRs that devs can leverage is really important as a way to jumpstart those larger projects. Or as a way to learn how to do something like creating a DAO, a swap, an IBC interaction, cross-contract calls and I could go on and on lol.

Great examples are Lumi’s randomized NFT minting contract, DDT’s secret RNG, etc.

Yes, I completely agree. Secret Boxes is meant to be a community effort – lots of potential ideas to help devs get going with specific use cases or technical how-tos. It’s not really like product development in that it has a set of criteria for completion. I see it as an ongoing initiative, with contributors adding new quickstarts as we evolve and depending on developer needs and interests.

The developer survey responses included lots of suggestions for tutorials and guides in addition so there’s plenty to do there and decentralizing this effort makes a lot of sense to me :smile:.

One thing I want to add is we need an audit team. Maybe down the road the committee can consider attracting and paying for people with those skills and expertise, that projects could apply for…

I think we all want to improve the developer experience on Secret and it’s just a matter of what, who, when and – funding.

SecretChainGirl supports your proposal :heart:.

3 Likes
#5

Hello Gino,

I absolutely love the idea of a dedicated developer support team. I believe “round-the-clock” developer support can make for a very desirable developer experience on the network which could, in turn, entice more developers to actually build on the Secret Network.

I also love the portion on mentorship. Being a developer is hard enough, but learning and developing with blockchain technology is still relatively new and is something even seasoned Software Engineers have difficulty understanding.

Do you have any more information on how you envision the mentorship program to work under your leadership?

3 Likes
#6

I imagine the program will get started with a few of the most recognized secret contract contributors to date. There are currently 3 who’ve expressed interest in committing 3 to 6 hours per week for pair programming sessions with qualified apprentices.

Secret Foundation has also said they’d help advertise this program.

I will help with the vetting, scheduling, and insuring the program meets a set of KPIs. A specific set of KPIs will be established as we get closer to launching the program. Off the bat though, things like program feedback scores, number of contracts added as a result of the program, number of funded projects as a result of the program, all seem like possible indicators to track.

1 Like
#7

Good idea, I would like to add something that is connected to the code audit. Perhaps all these repositories and commitments are properly audited either from SCRT Labs or an independent, experienced developer from the Secret Network.

Also, will there be any rewards for any developer or developer team to contribute to the Secret Network can be rewarded? I think the more we can push and incentivise for public access the more devs will be encouraged to build dApps on it. For instance, we have finalised SNIP20/SNIP24 token payments so any dApp who wants to have a subscription or buy a product/service can be integrated and used.

#8

We support this proposal and have 1 note.

We notice a substantially higher hourly rate. We understand that as a developer you have a higher hourly rate, but wonder how much of the 10 hours are actual development? Your knowledge is undoubtful of major contribution. As such we support it, but our expectation of your community leadership will be in line with the hourly rate asked relative to other leads.

#9

re: Developer rewards for contributing to Secret Network. Absolutely, the main function of the Community Code Repositories is to provide rewards to the developer or teams who build them.

It looks like there is strong support for this proposal both reflected here and also offline from members of Secret Foundation. The community also anticipates a strong and early demand for the mentorship program. As such, the Trivium node team and I have been discussing a way to increase the capacity of the Dev Lead role through a collaboration effort. Please expect an update to this proposal on Monday or Tuesday to reflect the details of a proposed co-lead Dev Committee.

3 Likes
#10

Hello All,

The Trivium team and I sat down yesterday and made some good progress. The funding proposal remains mostly unchanged with the exception of adding two new leads from Trivium!

Base Compensation Dev Committee Leads
Gino - $150/hr @ 10hrs/week - 4 remaining weeks in Q1 + 1 week back pay = $7,500 USD
Lumi - $150/hr @ 10hrs/week - 4 remaining weeks in Q1 = $6,000 USD
Xiph - $150/hr @ 10hrs/week - 4 remaining weeks in Q1 = $6,000 USD

We also setup meeting notes and an agenda system similar to the one Brendan uses for the Awareness Committee. We updated the committee charter slightly and also identified the first Community Code Repository to add to the list. (The Fund Forwarding Contract)

The meeting felt very productive and I’m looking forward to working more closely with them.

I will create a new thread that links to these documents if the proposal passes so we can leave this one for proposal discussion only.

If there’s any feedback to the new co-lead structure please comment now.

1 Like
#11

Why are you choosing to fund for 4 weeks? Typically these proposals are for 3 months. Are you going back to chain in a month?

#12

Yes, that was the idea…in order to stay in sync with two other committees

#13

Why do you need to be in sync with other committees? In the past we’ve always tried to not have multiple committee proposals in the on-chain voting period at the same time.

#14

Wasn’t aware of that but it could certainly be adjusted. It seemed like an easier mental model for myself and the community.

#15

The salaries are pretty high. I think that’s fine, top quality engineers are expensive and worth paying for, but I think that means high expectations as well.

My question is what is the structure of the mentorship program, and what should we expect in terms of outcomes? Sorry if this was talked about at the meeting. Are there any meeting notes you can share?

1 Like
#16

Thanks for your feedback. The best engineering consulting services I’ve ever received actually came at much higher prices than these! In general though yes, I think expectations need to be set high in order for the community to receive the most value.

Thanks for asking for the notes. I’ve gone ahead and opened them up now.

New Dev Committee Meeting Notes folder:
https://drive.google.com/drive/folders/1qDcnBeKcvGUD7YQ6DQ6pRJhXwrTWNasa?usp=sharing

2 Likes
Dev Committee Q2 Funding Proposal
#17

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
#18

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
#19

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
#20

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