Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)

Subject: Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-02 09:29:30

On Sun, Jan 2, 2011 at 8:50 AM, Edward Diener <eldiener_at_[hidden]> wrote:
> On 1/1/2011 9:12 AM, Dean Michael Berris wrote:
>>
>> I'm not about to impose anything on anybody -- I was under the
>> impression that decisions like these would be a community matter. In
>> that case, I don't see why I shouldn't try to ask everybody else to
>> change the way they do things because, well, the current process is
>> asking me to change the way *I* do things. ;)
>
> You still do not get it.

I think I do get your point, except that what I'm saying doesn't seem
to be making much sense -- or at least not conveying the fact that I
get your point. :D

I was actually agreeing with you when I said that the current process
will be supported by the "extended" version I'm proposing. ;)

> So here it is as plain as I can make it. As a
> developer potentially creating for Boost I am interested in creating
> libraries myself, documenting and testing them, then offering them to others
> to use and comment on. If I feel like the comments will improve the library,
> I will improve it. If others do not like the library they will not use it,
> or not want it to be part of Boost, or they will create their own library to
> do what I have done. I may work on a library with a very few other people if
> that suits me, but I feel absolutely no impetus to work in a collaborative
> environment with a group of people, each one of which can contribute to the
> library in their own way.
>

Sure, and the expanded process I'm proposing *doesn't* preclude this.

The current process actually prescribes what you're proposing which
isn't necessarily wrong, except IMO -- and the whole point of the
discussion really is -- it doesn't scale, which is the problem I
wanted to address.

You can go about doing exactly this what you describe in the expanded
process and it wouldn't be a problem. But if the expanded process also
accounted for *explicitly* another supported means for getting
libraries from the review queue to the main distribution -- to address
the scalability, continued maintenance, and lowered barrier to entry
for potential developers -- then I don't see why that would be a bad
thing. It's all a matter of tweaking the process to allow for a more
collaborative way of developing libraries, not saying that any other
way (the current way or the way you highlight) would be discouraged.

The irony of it is that that a more welcoming and collaborative
process also embraces a non-collaborative process as the degenerate
case. :)

> Shocking, isn't it. There are still a few souls like me that are not going
> to create software as a community effort of people, but individually as my
> own design and effort to do something as best as I can. That does not mean I
> would not ask or accept help from others or give help to others if I can.
> Nor does it mean that I am not appreciative of the knowledge of others and
> what they may have to tell me to improve my efforts. But it does mean that I
> have almost no interest in initially creating any piece of software as a
> community effort.
>

Not shocking at all, and I account for that in the process I describe.
The only difference between a more collaborative process and a process
that you describe is that: in your case, you just don't put the same
premium on the collaborative aspect. Your community can be a community
of 1. ;)

> With all that said my view of community effort is much less harsh than it
> may seem. Of course developers should be free if they have the desire to
> contribute their effort to a library which already exists, as well as work
> on a library initially together if they like. But you should stop
> proselytizing for this as the end-all and be-all of all software development
> in Boost, as if everything done must be some community of programmers in
> some sort of collaborative effort.
>

Hmmm... I don't think I should stop "proselytizing" mainly because the
point of starting the discussion is so that I hope to at least be able
to convince people that a different way might make sense for Boost. I
didn't say it was the end-all and be-all, I was mainly putting out
ideas for how to lower the barrier to entry for potential
contributors.

If I don't convince you, then that's alright by me. Although I say
again, what you describe would be perfectly fine in the process I was
describing a few emails ago. Now if others -- like me -- would like to
do it in a more collaborative manner than how you describe, I don't
see why the Boost policy or guidelines shouldn't explicitly allow or
at least encourage that as a means to scale the
development/maintenance/evolution effort to ensure that Boost keeps
going as an open source project that people want to contribute too.

HTH

-- 
Dean Michael Berris
about.me/deanberris