You are viewing a single comment's thread from:
RE: @timcliff's Witness Hardfork Approval Standards v0.1
This seems thorough. I was wondering about the tracking of tests and results with so many people testing. Sounds like each test will be a github issue and testers can comment with their results/concerns under each one? Or how is the info to be organized? (I’ve never used GitHub so not clearly able to visualize how the data will get organized. I’m more accustomed to spreadsheets.)
Posted using Partiko iOS
Tools for CI will auto-magically run the tests and publish the results in many cases. Only for the manual scenarios we will have go through the github issue scenario. When we get bug reports/issues, we can always prioritise them and fix. In a recent disaster resecue scenario around 1900 volunteers collaborated over github on a project and even with say, 1000 people testing/subimitting-PRs/fixing issues the management team which was hardly 6 people was above to handle the work load. Moral of the story is - anything possible with communities. There could be chaos in the beginning, but it will evolve into an orderly place very quickly.
Thanks for the clarification and example. Sounds like the manual scenarios aren't so plentiful that a hierarchical reporting structure is needed.
I think so. After I posted this comment, I just went and marked a PR as one needing review and testing ( https://github.com/IEEEKeralaSection/rescuekerala/pull/1003 ) so, once things stabilize we will not have trouble handing the project.
In RC changes and SMT changes there could be manual scenarios. Once we stabilize like the state where we are now, we will not need a very elaborate hierarchical structure. Numerous projects starting from GNU's GCC, Bash, Emacs, Linux Kernel all have tried and proved that the community approach will work. But yes, in most of the above cases, the community had a "benevolent dictator" or a well defined code-of-conduct.