Boost logo

Boost :

Subject: Re: [boost] [Boost-docs] Maintaining
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-05-25 09:32:58

On Tue, May 25, 2010 at 6:05 PM, Daniel James <dnljms_at_[hidden]> wrote:
> On 25 May 2010 03:27, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
>> So we still touch raw HTML? That's a little painful.
> Not really, HTML has excellent tool support. Several developers want
> to use WYSIWYG editors.

Well if absolutely necessary, then touching HTML shouldn't be hard. It
just somehow in my view is not a good use of time dealing with actual
raw HTML than a lighter representation like RST/Quickbook/HAML.
Although that's just me.

If WYSIWYG editors is what's needed, then I've seen one of the best
browser-based WYSIWYG editors already shipping in Wordpress so that
should be a welcome feature.

>> Even the web
>> designers/developers I know are moving to haml [0] which is a lot
>> friendlier for people writing code which eventually gets turned into
>> HTML by some processor.
> We can't really expect people to learn another technology and install
> another toolset. I think you need to understand HTML in order to use
> haml anyway.

Yup, that was a bad example -- and is mostly geared towards people
doing websites from scratch.

The point I was trying to make is if we can stay as far away from HTML
as possible, then that should be better than touching raw HTML, IMO.

>> There are also other tools like Jekyll [1] and
>> Sphinx [2] which deal with Markdown and Restructured Text respectively
>> to generate nice static web sites.
> The website predates both tools. Hyde would be a better choice than
> Jekyll since Python is preferred round here. I'd be a little worried
> about how flexible they are.

Yup, but if Python was preferred I'd think Sphinx would be a better
solution for documentation.

>> I agree, and it would be nice if we would use something like Wordpress
>> MU so that we can have library maintainers manage their own sub-sites.
> I'm trying not to be the voice of pessimism, but I don't think that's
> feasible. Library maintainers already have enough of a workload, and
> several libraries don't even have maintainers.

Sure, for libraries that aren't maintained or don't need a separate
sub-site, then the main boost site (or a page in the site)
would be sufficient in the meantime. I would say if someone else
wanted to step in an handle for example the sub-site for a particular
library (like Boost.Pool) then having a Wordpress MU installation
would make is significantly trivial to let that someone take over that
part of the site. Remember, one of the goals is to encourage
participation -- lowering the barrier to entry in terms of
contributing to "community building" would be, I believe, important to
getting more people involved at least in the web aspect.

For other libraries that already have a following, letting the
maintainer do things easily just with a browser should be a lot better
experience compared to the way things are going now. Coming with with
FAQ's, examples, and other specific pages just for a particular
library should be as easy as possible. Getting comments and feedback
from the users through the website should be the same as well.

>> I'm still toying around with whether
>> a web-based forum ala StackOverflow would work on a per-library basis
>> as well, which can be a totally independent feature should library
>> maintainers want them for their own sites or not.
> Why not just use StackOverflow? Since they've recently announced an
> API, it might be possible to integrate it into the site in some
> manner.

That's one possibility and it's still one of those things that begs
the question -- how hard/easy would that be? Unless there's already a
WP plugin for that yet, I don't see why we have to go through extra
effort to use StackOverflow from day 1. I'm positive there would be
one if there's not one already and it would definitely just be a
matter of installing and configuring that plugin when the day comes.


Dean Michael Berris

Boost list run by bdawes at, gregod at, cpdaniel at, john at