David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
I think boost should have a global TODO list. Posts in mailllists are easy to forget and hard to find.
<skipped>
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? http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/more/getting_st... 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 practice" statements. 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 discussions. 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. Andrey