[Freeciv-Dev] Re: Submit patch again?

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 12:10 AM 01/08/15 +0200, Thue wrote:
[...]
>I am sorry people feel that way - it is just a question of limited 
>man-power... proffreading and helping other people's patches can 
>sometimes be less efficient than working on your own.
>
>-Thue

This may be true, but it is not a good attitude or position to take 
once you move from being a contributor to managing the development
process. The goal of the management role is to get the most out of 
other people, not to optimize personal achievement. It is a hard
mind switch for most to make when the time comes. Also, you can get
10 times as much done when your knowledge is leveraged by 10 others.
The inefficiency in ramping them up is often more than outweighed by 
the new ideas and constant reevaluation of possibilities. So there 
are some fallacies in what you say as well.

Having said this, I think that most of the core people on Freeciv put
in an inordinate amount of effort, and are generally very responsive
in an admittedly difficult balancing act. Any occasional lapse during
stress periods is more than forgivable.

But there might be ways to improve the situation ...

Two, things that might help are some well known procedures and a policy
that every submitter gets at least one reply in a fixed period of time.

The procedures should enable a fast triage evaluation of a patch with 
minimal scrutiny, and a note that is sent sent back to the submitter 
that it was rejected, should be resubmitted with some critical elements 
reworked, or passed on to the next level. A patch gets 3 chances at
resubmission over its lifetime if you need a control here.

At the next level, worthwhile efforts and those on the list of desired
tasks should be assigned to someone to work with the submitter to cleanup 
any rough edges or bugs. After a reasonable period of time they face the 
same test, and are either passed into the final code review and checkin 
process, or rejected with cause or suggestions to rework and try again 
from the beginning.

Something like this would allow you to process a lot more submissions
quickly while still culling the noise and devoting sufficient time to 
things that are deemed worthwhile. Minimal changes or obvious bugfixes,
would clearly skip or spend minimal time in the shakedown stage.

Having a set of core team developers with expertise in appropriate areas
and an affiliated set of apprenticed "reviewers" to help spread the 
shakedown effort while also being trained in the intricacies of the 
codebase might help with the workload aspect.

This would also insure that work-in-progress stayed out of the mainstream
and some of the "pressure" induced errors from too speedy and untested
checkins would be minimized. Submitters are often willing to do a lot of
hard work to get things right when the goals are clearly attainable, which 
can ease the load on those one level up the food chain as well as make for
a much better product.

Cheers,
RossW