On Tue, May 25, 2010 at 6:05 PM, Daniel James <dnljms@gmail.com> wrote:
On 25 May 2010 03:27, Dean Michael Berris <mikhailberis@gmail.com> 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 boost.org 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. HTH -- Dean Michael Berris deanberris.com