Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LABS Proposal 2020 #63

Open
smk762 opened this issue Dec 18, 2019 · 0 comments
Open

LABS Proposal 2020 #63

smk762 opened this issue Dec 18, 2019 · 0 comments

Comments

@smk762
Copy link
Contributor

smk762 commented Dec 18, 2019

As the project matures, a little review and revision of structures, processes and workflows is probably a good idea. I have a few suggestions, and welcome views and suggestions so we can enter the new year with a clear plan and contingencies for when a pivot is required.

  • Expanded testing: Bug finds in dApps, Antara modules, and consensus code changes. Bounties to be determined based on severity of bug, with a baseline finders fee paid on acceptance by "bugmaster". Bonus bounty can be released according to NN votes periodically (e.g. alongside each HF vote for new NN)

  • Expanded crew: We are lacking a few roles which are required, and also descriptive role titles for existing core contributors. Someone to cover social media, support agent, marketing/outreach, onboarding, docs etc. Obviously we cant offer a wage for all this at the moment, but its good experience and when it all comes together and the work gets busy enough we'll be ready. In the meantime, some dev funds could be allocated based on level of contribution (via vote) or for specific tasks like docs. For those of us already heavily involved, we need to figure out our core responsibilities based on skillsets, and secondary collaboration duties - this should help with cross training of skills so we can cover when someone takes a holiday or is otherwise engaged in KMD / dayjob duties.

  • Git workflow: Early on, we've gotten into the habit of pushing directly to master branch. I'm guilty of this. Most of the time nothing explodes, but it's not ideal. We need to implement some form of code review and keep master stable until at least 2 people sign off on changes. This review should also assist with cross training, and learning/better understanding changes. Likely some docs or at least comments in code will be needed to avoid too many instances of "what does this bit do, and what does it mean?". Master branch updates should be less frequent, perhaps only at each 2 month HF / NN vote interval.

  • Scheduling: The plan was to HF with new changes every 2 months, and elect new NN ops. We have not stuck to this as often there was something else getting in the way. Ideally we can get in sync and set a firm day of each second month that this happens. Any "not reviewed/ ready" changes to master should be able to wait until the next HF. We have plenty of freedom to use CFEK changes in the meantime.

  • GUIs: Given my skillset is not advanced enough to tackle core changes yet, while learning more I'd like to put existing skills to use by creating some simple GUIs for things like voting. Also keen to streamline some of the visual metrics work as required, depending on what is being tested. Obviously some things being server-side CLI means GUIs are not an option, but I'm open to requests.

  • Meetings: This is a challenge due to the geographic distribution of contributors, but every 2 weeks we should have an hour where we can do progress / status updates, figure out what's missing, what went wrong, what went right, and praise or constructively criticize each other accordingly. This is the best way to track where we need to focus resources, learning etc. and find out who needs help with stuff. Pants optional, and there will be donuts.

  • KMD liason: We are a relatively unique ecosystem project, and there is great potential for mutual benefit via collaboration with KMD by providing a means for incentivised testing. Isn't it our reason for being? There is much testing going on in KMD on Antara modules, nSPV, apps, atomic swaps, and the gaming sdk. We should be able to incorporate more of that into LABS. This will also allow more community participation with ongoing challenges / bug hunts, along with a gentler learning curve for participation by community members who are still a bit green with Linux etc.

I'll add a few more things over the next couple of weeks, and appreciate any feedback or ideas others can offer. If we can come to agreement on the vision we want to achieve around new years, it should help pave the way for a worthy path through 2020.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant