On Sun, Jan 2, 2011 at 8:50 AM, Edward Diener <eldiener@tropicsoft.com> 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