LBRYCommunity/lbry-sdk
1
0
Fork 1
Code Issues Pull requests Projects Releases 282 Packages Wiki Activity
Page: Development Process & Standards
Pages
Branching and Merging Changelog Format Component Dependencies Table Credit calculation script DHT Resources Daemon docstring formatting Development Process & Standards Error Codes Home Labels Log Levels Managing Github notifications Managing Pull Requests RPC result verification FAQ Release checklist (daemon) Remote Debugging Run full local stack SDK Disk Space Management Settings Testing Wallet Server notes Zen of LBRY Development sdk structure in lex's rewrite
0 Development Process & Standards
Alex Grin edited this page 2019-07-30 09:33:00 -04:00
Table of Contents

Overview

We're doing Scrum-lite. Sprints start on Monday.

All times are US/Eastern

Sprint Board

The sprint board is here. Install the Zenhub extension if you can't see it.

Protocol team standups are at 10am, app team standups are at 11am.

Definition of "Done"

  • required work is done
  • tests for new work are written and pass
  • unit/functional/integration/regression tests pass
  • finished work was tested manually
  • its secure
  • documentation is written/updated
  • code is merged into master
  • code is ready to go live
  • team agrees item is done

Dev Process

  1. assign issue to yourself, mark it as In Progress
  2. code code code commit code test code commit test feedback code test ...
    1. n.b - a WIP pull request can be created here to solicit feedback
  3. squash/rebase code for sharing, write quality commit messages
  4. run automated linting/testing suite. if there are issues, goto 1
  5. test the code yourself (on every OS/platform/environment we support)
  6. document your changes in the changelog
  7. create PR (or update existing PR)
  8. assign someone to review and approve your PR. if reviewer raises any issues, goto 1
  9. squash fixup commits; merge your PR into master; delete branch
  10. close issue

Code Standards

  1. the maxims
  2. Every commit in master should work and pass tests/linting
  3. See Branching and Merging for how to git
  4. Commit messages should be informative, aimed at developers, and provide context/explanation for the change being made
  5. Commits on master should stand-alone
  6. Force pushes on feature branches are allowed; please commit early and often, but clean-up the mess before merging into master.
  7. Pull requests should have an informative changelog entry (see changelog format). The changelog is aimed at downstream developers and technical users. This is slightly different from commit messages.

Code Review

  1. Reviewing code takes priority over writing code. Code waiting for review means that somebody else is blocked. Be a good teammate. Also, code that is written but not merged is wasted inventory and expensive.