From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-07-13 13:23:41
David Abrahams wrote:
> Andrey Melnikov <melnikov_at_[hidden]> writes:
>>David Abrahams wrote:
>>>Andrey Melnikov <melnikov_at_[hidden]> writes:
>>>>I think boost should have a global TODO list. Posts in mailllists are
>>>>easy to forget and hard to find.
>>It isn't referenced on the home page.
> Sure it is. "Request Support" in the left-hand column. It probably
> could be more prominent, and more routes to the tracker should be
> better emphasized, e.g. through the "Report Bugs" and "Suggest
> Features" links. Those two pages tend to discourage using the
> tracker, but now that tracker entries get automatically sent to the
> lists, I'd say we should explicitly encourage it and discourage
> sending these reports to the lists.
Not in the left-hand column. That page is outdated. The new design has
this link in the left-hand column, and it's even less prominent than on
the previous design. At least I failed to find it when I explicitly
searched for it and I knew what I was looking for. But now I looked
again and found it.
>>A lot of people who know that such a tracker exists on Sourceforge
>>won't use it because some SF projects doesn't use the tracker.
> I think mostly it doesn't get used because it's inconvenient for the
> bug reporter,
The only way to avoid such inconveniences is to start Boost.Tracker
project :) From my practice no existing trackers are good enough to be
called "universal". Some like Rational ClearQuest are extremely
customizable, but customization takes ages and such guns are too big and
sometimes are too expensive too.
> and because the mailing list tends to work most of the time.
The volume of the mailing list is much larger than the number of items
on TODO list. We cannot easily calculate how many issues we forgot to
fix. For example, why recent discussion about Getting Started guide
isn't integrated into CVS?
is an old one.
>>If the tracker is actively used (and from SF page it seems so), it
>>should be referenced in participation/contribution sections along
>>with mail lists.
> Can you post suggested patches to the CVS version of the site?
I'll try. First, I'd like to express bad things in Participation section.
1. We don't need the first paragraph:
> Although Boost was begun by members of the C++ Standards
> Committee Library Working Group, participation has expanded to
> include thousands of programmers from the C++ community at large.
This is "Background" information. (I dislike the "Background" header on
the page though) It doesn't help people wanting to contribute to get
involved, and doesn't help Boost to involve more potential contributors.
2. Participation section should tell people *why* they should
participate, *how* they can help Boost, *how easy for them* and *how
useful for them* their participation can be.
Just like all free software projects, Boost doesn't pay salaries to its
developers. And most competent commercial developers will refuse to
participate actively in writing free code. On the other hand, getting a
lot of real-life feedback is essential for Boost to be a successful project.
People can contribute without a need to write actual code. They can help
Boost to be better by providing arguments other people missed, by
pointing to weak places in the design, by suggesting the changes they'd
like to get.
Many people can actually benefit just reading the discussions. Most
discussion end with highly grounded and highly practically useful "best
I'd like to have a more informative and motivating description there in
Participation chapter. Current information can be placed on a separate
page. I'll try to create my version tomorrow.
Personally, I fear joining "developer mailing lists". I don't like to
read discussions of diffs in code I don't understand and don't use. In
my spare time I don't like to get CVS access, get assigned to some
tasks, and check in changes.
I use Boost so called "developer" mailing list for the reasons I didn't
realized when I subscribed to it.
Pure "development" part, at least in this pre-release period, is about
regressions for specific compilers, and I ignore such threads.
But I do read threads like "MS compiler detection" and "Defining
compiler suggestions" because I can use that information in my daily
work. The amount of fresh ideas and reusable idioms is impressive.
The original reasons were to get performance issues in Date_Time and
lexical_cast fixed so I won't have to apply my own patches every time I
migrate to a new version.
Now I use it because the list is a pretty good advanced C++ community.
The discussions are really *highly* technical. No simple "which API call
to use" or "help me with my college assignment" questions. No flames. I
really learn "best practices", I learn more high end C++ every day by
reading questions and answers and actively participating in non-trivial
Also I learn more about Boost and its libraries, including very
important practical applications. The list is much better than just a
documentation, and the list is an extremely useful component of the project.
My propositions don't get rejected because I don't want to implement
them myself, they don't get rejected without a high motivation, without
*highly technical* reasons. I always get a competent answer and if I
don't agree, I can continue arguing until all my arguments are over, or
until my opinion is accepted. No people have hard-coded stereotypes, no
pattern thinking, no argumentation based just on "trustworthy" opinions.
Of course I wouldn't publish such a complimentary ad on the website, but
current description is non-informative, misleading and scary.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk