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

Subject: [boost] [proposal] The boost.org Maintenance Effort
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-05-25 22:49:11

Hi Everyone,

[First of all, this is a warning -- this is a long post, and I would
really appreciate it if you read through the whole thing first before
posting a comment on any specific thing I say. What follows is more
supposed to be read as a document, so please bear with me. :D]

A couple of days ago I posted a question about who is managing the
boost.org website and the current process by which the website is
being generated/hosted. That discussion led to a few realizations for
me that I am including in this proposal to address the relative "pain"
required to maintain the current site and move forward.

This post is a proposal is designed to address three key areas of the
boost.org maintenance effort:

  * The toolchain requirements for building/generating the boost.org site.
  * Addressing the non-interactivity of the boost.org website and the
related pages.
  * Per-library community/documentation management.

First, a preamble:

The boost.org website is meant to be the face of the Boost C++
Libraries. It should be the facade that communicates the quality and
the high standard the the Boost development community hold dear as the
differentiating factors that make Boost what it is. As the face of the
community, the website should encourage: participation, collaboration,
community building, and open communication. The website shall host all
community-developed and enforced policies, all official communications
from the Boost community to the world, and serve as an umbrella that
shelters the libraries and communities that do become part of the
Boost C++ Library effort.

Next, let me outline a few broad things with specific points:

Communication

  * We should make it easy for the whole boost community (boost.org)
and individual library maintainers/community to communicate messages
to the world at large in an easy, unobtrusive manner.

  * We should make communication a two-way process by encouraging
participation (see Participation below).

  * We should strive to communicate more, instead of communicating
less -- to do this we should make it part of the goal of those in the
Boost community (not necessarily developers) to promote the libraries
and the website itself.

Participation

  * Let's encourage participation in the form of comments to blog
posts, feedback on documentation pages, and discussions on specific
topics/threads.

  * Let's make it easier for non-developers to contribute to the
effort in the form of community building, providing support, and
advocate the library.

  * We should use the boost.org website as a means of reaching out to
and being one of the ways the open source community and industry at
large can get in touch with: individual developers, library
maintainers, or the Boost community (including users) at large.

Collaboration

  * Let's add the boost.org website as an additional channel through
which collaboration can occur as a complement to the boost-developers
and boost-users mailing lists.

  * Let's foster a more community-driven way of solving problems
without having to require everyone to be part of a central list.

  * Let's allow communities around Boost libraries to grow and get
things done on the boost.org website.

After all the "marketing" stuff above, I'll outline below the concrete
steps I propose people allow me to do. Ultimately though there should
be a means of measuring whether the steps I take would lead to an
agreeable measure of success, so I point out some measures by which
you may hold me accountable to getting done. I invite everyone to
please comment on and discuss whether the steps/proposal makes sense
and whether there is a better way you think I can achieve this in case
you agree to my above statements.

Step 1: Move static and not-so-static content over to Wordpress MU [0]

The current boost.org website is composed of mostly static content
that says things about the submission-review process, the guidelines
for libraries, what the goal of the project is, and the like. These
pages can be ported to Wordpress MU manually either by copy-pasting
the content into the WYSIWYG editor or typing the content in (and
editing it in the process).

This step will include the establishment of who would be the
administrators and the eventual maintainers of the boost.org facade.
All the information regarding the Boost Community and the maintaining
of the content that's specific to the boost.org website would be
written, article submissions curated, and copy-edited by the
administrators.

I have personally volunteered to be one of these administrators who
would basically act as an editor for the site. I would take on the
responsibility of achieving the following (measurable) goals:

  1. Establishing a "Feedback" button that allows anybody visiting the
site to post feedback on whatever they think. I would prefer to use a
service called Get Satisfaction [1] to gather and manage the feedback,
as well as responding to feedback posted through that service.

  2. Incorporating a DisQus [2] discussion system to manage comments
on pages. There is already a Wordpress plugin for this and comment
moderation would mostly be handled initially by me and other
administrators interested in helping out in this effort.

  3. Integrating and publishing regularly the Google Analytics and
Wordpress MU stats on the whole site. Regularly can mean either
monthly or weekly depending on who often the community wants
information about the site.

[0] http://mu.wordpress.org/
[1] http://getsatisfaction.com/
[2] http://disqus.com/

Step 2: Make it easy to jump from Wordpress MU to Trac for the Wiki,
Tickets, and Source Viewer

This would mean adding links to the appropriate pages in Trac, and in
these pages a way to jump back to the boost.org website. This will
require some changes in the Trac site which should be easy to pull
off.

The measurable outcome for this would be to see the actual integration
done in a satisfactory manner. Satisfactory of course means, that it
works. ;)

Step 3: Set up blogs for individual libraries (who want it, or at
least for library maintainers/volunteers who want to manage it)

Ideally this should be done for all the libraries. Each sub-site would
include (at the minimum):

  * A blog -- where only the maintainers and those nominated by the
maintainers to have blog posting access can communicate what's
happening, what's coming, whether they need help, or whether there are
any nasty bugs that need attention (as well as just some general
updates or cool findings regarding the library).

  * Static Pages -- typically there would be pages like "About",
"History", "Examples", and "FAQs" which generally are mostly static.
These can be edited by the maintainers and those nominated by the
maintainers who would have access to these pages.

  * Support Information -- this would be a special static page which
would point to Trac, or other places where the development and support
system of the library is hosted. I am not excluding the possibility of
having libraries developed in github/gitorious/sourceforge. Links to
things like the mailing list on which the discussion happens, whether
there's a web-based forum, or whether there's a number/company to call
for support would generally go here too.

  * Online documentation -- as an absolute minimum there should be a
page on documentation for each library in Boost accessible from the
boost.org website. It would be a good thing to integrate the generated
library documentation into the wordpress system itself, but at the
minimum links to the generated library docs that are statically served
(just like now) would be acceptable.

My personal vision for boost.org would be to become the hub over which
the Boost C++ community and the surrounding ecosystem of companies can
join in on the action.

I would even go so far as say that we should encourage and allow
industry players that offer support for Boost libraries or who use
Boost libraries to place advertising on the site to help with
shouldering the cost of BoostCon, or other things that the Free
Software Conservancy would deem necessary to spend money on.

I also would like to see it be the face of the Boost community, and
really a means to get users to start using boost, get excited about
it, and eventually contribute back to the cause.

Users who are already passionate about providing support for a wider
audience of Boost users could also contribute to the cause not as
library developers but people who publicize and liberally put links to
the boost.org site on their blogs, on their email correspondence, and
in stackoverflow.com answers.

Ultimately I would personally want to see boost.org be able to handle
the growth of the Boost C++ Library, and allow for more communities
(not just one community) to through the site. I don't want it to
replace the mailing list for Internet old timers like me who like this
feel of email conversation, but for things like announcements and
communicating to the wider audience I think the website should do that
job superbly.

Thanks for reading this far, comments, suggestions, reactions, and
pledges to help would be greatly appreciated.

Have a great day everyone and I hope to hear from you soon!

-- 
Dean Michael Berris
deanberris.com