Community Development code of conduct - draft

PlatON Global Development & Technologies
#1

PlatON development code of conduct

Background: PlatON developer community has attracted more and more teams globally, till now PlatON has issued over a hundred grants, millions of LATs distributed. I have observed a lots of great questions from excellent developers, and their solutions could help the community, but didn’t got any exposure yet. It is a waste of resource.

PlatON is an open sourced community, a public chain ecosystem, the openness and transparency of developer community is the first we should have. In this article I have listed up a few items as a simple guide.

The open source development model has unique characteristics when compared to the traditional software engineering cascade model. It is fully github driven.

Typical development life cycle

  1. collect requirements, confirmation of requirements

  2. design

  3. implementation and swift testing

  4. release, and maintenance

Collect requirements, confirmation of requirements

For self driven DApps with independent implementations, can skip this step. Do you best to come up with brilliant design, you own and run DApp economy, and enjoy it

Here I am more focus on projects which impacting heavily on existing PlatON users, this step is VERY important, and we suggest

  1. set up a discord channel for timely Q&A, which will help you understand requirements, get efficient feedback, and have deep discussions with experts

  2. make sure environment requirements, build up proper testing environment

  3. fork the proper branch of proper project from github, you name it :wink: Kickoff project with records open online

Design

  1. hot topics to be published and debated in forum

  2. documentations to be published on the web via github for community feedback, since there are always great comments from smart guys, we could keep improving

Implementation and swift testing

This part is more developer specific, we should follow open source github development steps. For example

  1. assume the team has picked the proper project, proper branch as base. PlatON takes develop branch as base for all projects.

Here is an example: GitHub - PlatONnetwork/browser-server at develop

  1. ask github admin to create YOUR working branch under proper project, your name it :wink:

admin create: GitHub - PlatONnetwork/browser-server at feature-rich based on above develop branch

  1. each developer in your team fork this project to your own github, enter developing mode

a) star it by click right top “star”

b) fork it by click “fork”

c) linux commands below to have source code in sync locally


> git clone git@github.com:<your-githubid>/browser-server.git

> cd browser-server
> git remote add forkfrom git@github.com:PlatONnetwork/browser-server.git
> git fetch
> git branch -v -a

Till here, you should have all the branches available on your local working folder

in case you have forked too early without having this new working branch, then do the following to catch up

> git checkout feature-rich
> git merge forkfrom/feature-rich
> git push origin feature-rich

d) switch to target branch (here is the feature-rich branch), get up to date by merging with develop branch

> git checkout feature-rich
> git fetch forkfrom
> git merge forkfrom/develop

e) add tasks, issues, assign to proper developer, working on it

f) once task complete or issue fixed, submit to personal github respository, test it out

> git add ...
> git commit ...
> git push ...

also record issues found during local test, breakdown and record tasks on github with assignees

g) submit PR and ask to merge to proper branch

> submit PR from github web, to ask admin merge new features to forkfrom/feature-rich

Release and maintenance by admin

  1. merge into a test branch (for example: feature-platon-1.1.5)
  2. complete front to back test, send back feedback or issues to developers
  3. merge into develop branch to staging the release

follow ups

  1. when all work done, remove current working branch
  2. if still want to continue, you need to
> git fetch forkfrom
> git merge forkfrom/develop
> git merge forkfrom/feature-rich

(two useful status confirmation commands here)
> git status
> git log --all --decorate --oneline --graph

after confirm your working branch up to date, continue the rest of the work ...
1 个赞
PlatON开发行为准则 - 草案
#2

How to make perfect commit?

A perfect commit must be right changes with specific & meaningful descriptions.

  • here right changes from developers are efficient codes with clear comments, logically correct.
  • specific & meaningful descriptions refer to the comment when you do
git commit -m "write specific & meaningful descriptions here"

DON’T: please do NOT commit unrelated changes in one “git add” and “git commit”. You will find it is difficult to explain what was the change. And others may get lost when do the code review and merge

Useful command, use below command to break down multiple changes to meaningful patches

 git add -p <fileName>
#4

Regarding unit test

Unit testing is based on the public methods of the class. It is recommended to add unit testing in the following scenarios.

  1. when logically complicated, it is difficult to cover every branches during system test. So leverage unit test to check out methods interface, parameters
  2. different parameter combinations, edge cases, special values to be unit tested
  3. if dynamic user input scenarios related such as smart contracts, unit tests for boundary values ​​and missing input are required.
2 个赞
#5

Regarding local testing

  1. build up local single node chain (be careful of package version, dependency lib versions) is a low cost way for initial testing
  2. try start chain node with huge data( e.g. 10 years data), since blockchain tends to run forever
2 个赞
#6

Checklist

This is to help you organize your process.

  • Did I create my branch from development?
  • Did I follow the correct naming convention for my branch?
  • Is my branch focused on a single main change?
  • Do all of my changes directly relate to this change?
  • Did I rebase the upstream development branch after I finished all my work?
  • Did I write a clear pull request message detailing what changes I made?
  • Did I get a code review?
  • Did I make any requested changes from that code review?
#7

我其实有这么几个不关于技术的问题：
1.技术这么屌，Toke的价格这么拉垮，实在是想不懂
2.Bnb，Matic，Avax都是技术+ Toke不错的价格，我们怎么做不到
3.跌破0.12 :heavy_dollar_sign:发行价是什么鬼？

#8

不是说不关注技术，就是有这么几点好奇的地方 :joy:

#9

项目方不做市，走非同寻常的路子，想掀起一股币圈的清流。画虎不成反类犬，这样下去估计会死的很难看。

#10

实际上这个项目技术也没什么特色，无非就是把eos等一些项目的技术点整合起来，说得好听点叫借鉴，难听点叫盗取。

#11

understood your concern, it is out of my reach :frowning:

#12

能说中文么，亲(●✿∀✿●)