Who’s contributing to Pocket Network?
Some history
Pocket Network is an open-source protocol built by a community of creators. That initial group of creators was structured in a company named Pocket Network, Inc. (PNI) We’ve decided companies are dumb, but we have yet to throw the yoke of the corporate entity because it protects the original builders and allows us to do business with other businesses that want the same protection for their people.
Who’s building it now?
Contributors (you, me, and everyone else who wants to). Mostly developers and node runners, but everyone with the gumption to build can contribute and benefit from their efforts. It’s not all technical skills needed either. We need a diversity of opinions and actions to make Pocket as good as it can be.
While PNI continues to be the gold standard when it comes to how coordinated contributors operate, we want that to be a relic of the past in the very near future. Do us all a favor and build make PNI irrelevant…please.
What do I work on?
There are a bunch of ways to get involved and decide what to work on. Simply head over to the needs section of the forum, respond to an RFP, or just find something that needs to be built by playing around on Pocket. A few thoughts to think about:
- Of all the projects currently underway, what’s the most valuable thing I can be working on?
- Which project will have the highest direct impact on our customers? How much will the work I ship
benefit them? - Is Pocket not doing something that it should be doing?
- What’s interesting? What’s rewarding? What leverages my individual strengths the most?
What projects are happening at the moment?
You can check out a current list of things going on in projects, but by far the best way to find something that suits you and your skillset is to just start digging in. We are ALWAYS looking for smart people to help build Pocket. If you speak up, we’ll listen and point you in the right direction.
Often, it helps to know what you care about, what you’re good at, what you’ve got experience with, and the glaring holes you see but others don’t, and so on. And the way to get the word out is to start broadcasting all of this information. So, while you’re getting the lay of the land by learning about projects, you’re also broadcasting your own status to the community.
General Project Management Structure
Project Lifecycle
The goal of this process is to weigh various opportunities that have presented themselves to the ecosystem team against each other in order to establish a budget that fits within our runway objectives.
Units of Work: Projects
Projects are the smallest unit of work that is evaluated in the Pocket Network ecosystem. Projects can be defined merely as an idea that adds value to Pocket Network and requires a budget. These ideas go on to be fleshed out and are evaluated for their merits in the form of impact to the project, time, and funding required. Basically, a project is anything that requires a budget (time and/or financial resources) to execute.
For the purposes of DAO, projects that can be executed by groups of community members without funding should be executed outside of the approval process. Meaning, if you have the resources and time, don’t wait for approval to start working on it, (especially if it fills a need). If you’re not sure, put it out there and have the community comment on your project.
OKRs
As an evaluation goal-setting standard, we are adopting Objectives Key Results (OKRs). The Pocket DAO will create and periodically release a set of OKRs to guide the community’s efforts. For more information on OKRs, please see “Goal Setting with OKRs” and our guide here.
Planning, Budgeting, and Approval
How to get started
Projects generally start with an idea where the leader (could be the person that came up with the idea or someone else that wants to run with the idea) spends the time (within reason) to flesh out the idea and propose it for funding. During this process of idea to the proposal, we recommend consulting other contributors, subject matter experts, and community members for buy-in and validation of the idea. Generally, we believe in lean startup principles and it is expected that contributors bootstrap until budgets are deemed necessary to accomplish the goals - meaning don’t wait for funding to start.
Once enough critical mass has been established, a team that can execute forms, the project has been well defined, and there is a present need for funding, a formal proposal may be created and submitted for approval on a rolling basis.
At a high level: Idea > contributor/expert feedback > community buy-in + evidence > proposal (if necessary) > approval (if necessary) > funding (if necessary)
Some projects will be long-term (such as updates/newsletters) and some projects may have a very defined lifecycle. Projects should indicate their length and renew prior to expiration if they are an ongoing project. Expect that the DAO may choose to perform an RFP for renewing projects.
Execution
Do what you said you were going to do. Measure the results along the way and make sure to report to the community and other constituents how your project is going.
Things to think about as you execute:
- Are you tracking toward your OKRs?
- If there are roadblocks, what is the root cause of your challenge? Often this is two or three levels deeper than you think it is.
- What’s are the biggest successes or challenges of the project?
- Can anyone else in the community help me reach my goals?
As we execute a project it’s important to constantly test our own decisions. This is especially important when we embark into new territory. We’ve found that things often look different on the ground than they do on the map. That’s why we’ve found it vitally important to, whenever possible, not operate by using assumptions or unproven theories from our project plans.
Deliver and Debrief
Always ship. After shipping, projects will be evaluated against their stated OKRs. This will cause the cream to rise to the top over time and ensure we aren’t investing in projects that aren’t yielding results. Projects that have been approved should submit briefs justifying their budgets (and increases or decreases) ahead of quarterly meetings.
What if I fail?
Failing is part of the process of building risky things. We’ve done it hundreds of times. We’ve built things that no one used and we’ve built things that people used in unexpected ways. It’s part of the process and we try to view failures as learning opportunities. If you fail, don’t run and hide. Be transparent and tell the community what you learned. If you feel like you’re falling off the cliff, cry out for help - someone will always lend a hand.
That said, there are some bad ways to fail. For example, repeating the same mistake over and over is one. Another is not listening to customers or other contributors before or after a failure. Always pay attention to the data, don’t ignore the evidence especially if it doesn’t support your conclusions.