[Freeciv-Dev] Re: Submit patch again?

[Reinier Post <rp@xxxxxxxxxx>]

On Tue, Aug 14, 2001 at 10:31:41PM -0400, Ross W. Wetmore wrote:
> 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.

This has nothing to do with attitude.

Many patches have been ignored in the last year; Thue at least rescued
a few of them.  You can't blame Thue for not doing a job that nobody
else is willing to do.

The alternative is a change of policy: allow people to put their own
patches in without any checking from others.

> 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.

In the Freeciv project, there are no 10 others.  It's hard enough to
find 10 people with patches.

> 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.

OK, this process could be streamlined by adding some web forms and better
database support.  But the basic problem is: not enough people are willing
to look at somebody else's code.  Am I wrong?

> 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.

I can be a reviewer for a small part of the code base.  I'm also willing
to help set up some web/database support.

> 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

-- 
Reinier