Re: On cooperative work [Was: Re: newbus' ivar's limitation..]

On 8/1/12, Arnaud Lacombe <lacombar_at_gmail.com> wrote:
> Hi,
>
> On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao <attilio_at_freebsd.org> wrote:
>> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe <lacombar_at_gmail.com>
>> wrote:
>>> Hi,
>>>
>>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao <attilio_at_freebsd.org>
>>> wrote:
>>>>
>>>> You don't want to work cooperatively.
>>>>
>>> Why is it that mbuf's refactoring consultation is being held in
>>> internal, private, committers-and-invite-only-restricted meeting at
>>> BSDCan ?
>>>
>>> Why is it that so much review and discussion on changes are held
>>> privately ?
>>
>> Arnaud,
>> belive me, to date I don't recall a single major technical decision
>> that has been settled exclusively in private (not subjected to peer
>> review) and in particular in person (e-mail help you focus on a lot of
>> different details that you may not have under control when talking to
>> people, etc).
>>
> Whose call is it to declare something worth public discussion ? No one.
>
> Every time I see a "Suggested by:", "Submitted by:", "Reported by:",
> and especially "Approved by:", there should to be a public reference
> of the mentioned communication.

Not necessarilly. Every developer must ensure to produce a quality
work, with definition of "quality" being discretional. Some people
fail this expectation, while others do very good. As a general rule,
some people send patches to experts on the matter and they just trust
their judgment, others also full-fill testing cycles by thirdy part
people, others again ask for public reviews. Often this process is
adapted based on the dimension of the work and the number of
architectural changes it introduces.

As a personal matter, for a big architectural change things I would
*personally* do are:
- Prepare a master-plan with experts of the matter
- Post a plan (after having achived consensus) on the public mailing
list for further discussions
- Adjust the plan based on public feedbacks (if necessary)
- Implement the plan
- Ask the experts if they have objections to the implementation
- Ask testers to perform some stress-testing
- Ask testers to perform benchmark (if I find people interested in that)
- Send out to the public mailing list for public review
- Integrate suggestions
- Ask testers to stress-test again
- Commit

I think this model in general works fairly well, but people may have
different ideas on that, meaning that people may want to not involve
thirdy part for testing or review. This is going to be risky and lower
the quality of their work but it is their call.

>> Sometimes it is useful that a limited number of developers is involved
>> in initial brainstorming of some works,
>>
> Never.
>
>> but after this period
>> constructive people usually ask for peer review publishing their plans
>> on the mailing lists or other media.
>>
> Again, never. By doing so, you merely put the community in a situation
> where, well, "We, committers, have come with this, you can either
> accept or STFU, but no major changes will be made because we decided
> so."

You are forgetting one specific detail: you can always review a work
*after* it entered the tree. This is something you would never do, but
sometimes, when poor quality code is committed there is nothing else
you can do than just raise your concern after it is in.

> The callout-ng conference at BSDCan was just beautiful, it was basically:
>
> Speaker: "we will do this"
> Audience: "how about this situation ? What you will do will not work."
> Speaker: "thank you for listening, end of the conference"
>
> It was beautiful to witness.

Not sure if you realized but I was what you mention "Audience". I
think you are referring to a specific case where a quick heads-up on a
summer of code project has been presented, you cannot really believe
all the technical discussion around FreeBSD evolve this way.

>> If you don't see any public further discussion this may be meaning:
>> a) the BSDCan meetings have been fruitless and there is no precise
>> plan/roadmap/etc.
>>
> so not only you make it private, but it shamelessly failed...

And so? I think you have a wrong point of view of what is
shamelessly... I'm working on the same project since 6 months, i
thought I could finish it in 1 but then I understood that in order to
get the quality I was hoping I had to do more work... does it qualify
as failed, according to your standard?

>> b) there is still not consensus on details
>>
> Then the discussion should stop, public records are kept for reference
> in the future. There is no problem with this.
>
>> and you can always publically asked on what was decided and what not.
>> Just send a mail to interested recipients and CC any FreeBSD mailing
>> list.
>>
> This is not the way "openness" should be about.

There is not much more you can do when people don't share details and
discussions automatically.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein