Re: [boost] [proposal] The boost.org Maintenance Effort

Subject: Re: [boost] [proposal] The boost.org Maintenance Effort
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-05-26 22:44:07

On Thu, May 27, 2010 at 1:08 AM, Robert Ramey <ramey_at_[hidden]> wrote:
>
> I am very skeptical of "fancy tools". Â They tend to make things "simpler" by
> hiding how things work. Â The tools look great when you demo them but when
> you actually try to use them you find yourself trying to "trick" the tool
> into doing what you want. Â Eventually users catch on to this and then become
> customers for the next "solution". Â It becomes an endless cycle of adding
> "cool" features then spending a lot of time to keep them working. Â This same
> problem infects all of modern life. Â The VCR mentality has spread like a
> cancer.
>

Okay, but Robert this is a generalization. I can think of fancy tools
that don't really need to hide how it works for it to do something
very well without the user having to know how it works to use it well.
The car is one example.

I would argue that the difference between a Rube Goldberg machine and
a black box only matter if either one doesn't do what it's meant to do
-- in that situation it doesn't matter which one shows how it works
because if it doesn't do what it's supposed to then it's moot. There's
a reason people have stopped writing their own CMS systems and it's
because there are already CMSes out there that do what they need to do
without having to know how it does it.

Think of it like a driver instead of as a mechanic -- if Wordpress'
interface doesn't work for you if all you want to do is to post a blog
entry, then Wordpress is wrong, it shouldn't (and largely, doesn't
really) matter how it does it. :)

> The current concrete example is the boost.org website which uses a few of
> these "fancy" tools and has become hard to extend in the way we want.
>
> Soooooo ..... Just one man's opinion that the focus on tools is overdone.

Fair enough, but the current tool-chain is what I think is the barrier
to entry for people who just want to contribute to putting content up
on boost.org (and for individual library sites).

> I
> would like to see a discussion about the structure of a "new" website before
> getting into the "tools". Â Of course I said most of what I wanted to say
> about this subject in our discussion regarding this subject at BoostCon.

That sounds like a good discussion to have. If it wasn't clear in my
proposal, I apologize -- what I wanted to achieve was something like
this:

  www.boost.org
    - all about boost the community, the library collection, the
process, the policies, the people
    - guidelines for the website, necessary disclaimers, etc.
    - a means for jumping to the individual library subdomains
  <library>.boost.org
    - blog
    - online documentation
    - support information
    - discussions (?)
    - static pages (FAQ, History, etc.)

As long as there won't be a Boost.WWW (a world-wide-web library) and a
Boost.SVN (an SVN library) this structure should be as scalable as the
DNS system is. It's flat, it's simple, it's consistent.
[snip]
>
> Each library page - similar to what I presented as an example - see
> http://www.rrsd.com/software_development/boost/BoostCon2010/library_status.html
> This page would be mostly links to deployment. Â issue tracking, forums/list.
> That is, the implemention of each of these aspects would be left to the
> developer. Â Some libraries need only the simplest of discussions - e.g.
> state_saver, Others need the full blown Track or similar system.
>

And this page would fit well (and would be easier to do) with
Wordpress in your own subdomain. So you can imagine having a
serialization.boost.org subdomain where you have a
serialization.boost.org/status page where you can really pretty much
do whatever you want. ;)

> The lack of  a "unified" system will be found to be off putting to some -
> but this methods lets Boost evolve as necessary.
>

I agree 100%.

-- 
Dean Michael Berris
deanberris.com