> First, each release, or between different releases, would have tasks > included. Among tasks there might have priority between those tasks or > a task may block one or more tasks. So how do we determine priority of > tasks or that between several releases? An naive thought is by voting; > however, issues may not be clear for every participants. In that case, > voting may defer more important tasks.
I think we can follow current guide line. "Every ideas for improvements, new features, and suggestions are recommended to be discussed in polite terms before implementation on the dev@ list, and then its decisions must be listed on our RoadMap page. In simple improvement or bug type issues, you can skip the discussion and report directly on JIRA." And then, we can cut a release according to the Roadmap. > a.) when a patch is submitted, at least 2 reviewers should help review > source code. > b.) the patch creator should describe e.g. execution flow/ procedure > in a higher/ conceptual level. > > Reviewers then can cooperate review parts of the code in patch (tool > may help in this stage). Some review points such as (java) doc and > test cases should be included. > > - Test cases > Each patch should have test cases that at least capture the main > logical flow. And the tests is recommended not to bound to external > dependencies so that time spent on testing can be reduced. > > - Doc (Java doc or wiki) > Class should at least describe what it is, or its main logic flow. Or > at lease write down the mechanism in wiki. Method fields that is not > self-explanatory would be good to have doc explaining its purpose or > its execution mechanism. +1 On Mon, Aug 5, 2013 at 11:33 PM, Chia-Hung Lin <[email protected]> wrote: > As hama community grows, it seems that it is good to have a guideline > so that participants can follow and cooperate more smoothly. Therefore > I would like to discuss about this, and please share your opinions so > that we can improve the process. > > Below are some issues popping up on my head. > - roadmap prioritization > - development work flow > > First, each release, or between different releases, would have tasks > included. Among tasks there might have priority between those tasks or > a task may block one or more tasks. So how do we determine priority of > tasks or that between several releases? An naive thought is by voting; > however, issues may not be clear for every participants. In that case, > voting may defer more important tasks. > > Second, a few subtopics are listed as below: > > - Code review > Though a commit section is described, it is not clear how the > procedure will be practised. My thought is > > a.) when a patch is submitted, at least 2 reviewers should help review > source code. > b.) the patch creator should describe e.g. execution flow/ procedure > in a higher/ conceptual level. > > Reviewers then can cooperate review parts of the code in patch (tool > may help in this stage). Some review points such as (java) doc and > test cases should be included. > > - Test cases > Each patch should have test cases that at least capture the main > logical flow. And the tests is recommended not to bound to external > dependencies so that time spent on testing can be reduced. > > - Doc (Java doc or wiki) > Class should at least describe what it is, or its main logic flow. Or > at lease write down the mechanism in wiki. Method fields that is not > self-explanatory would be good to have doc explaining its purpose or > its execution mechanism. > > Just some ideas I have at the moment. Will add more if I find others. > And we should keep improving it when necessary. Please add your points > if you think some are missing, or remove some that is not needed. > > [1]. How to commit - Review https://wiki.apache.org/hama/HowToCommit#Review -- Best Regards, Edward J. Yoon @eddieyoon
