[proposal] The boost.org Maintenance Effort
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
At Wed, 26 May 2010 10:49:11 +0800, Dean Michael Berris wrote:
Step 1: Move static and not-so-static content over to Wordpress MU [0]
Yay. Consider also whether you want to go a little further, to buddypress. Also consider that WP 3.0 is imminent and it is supposed to include all the MU functionality natively.
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).
The WYSIWYG editor has an “HTML face,” so there's no need to retype anything.
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.
Awesome.
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.
My only reservation is that I tried a similar plugin (http://wordpress.org/extend/plugins/intensedebate/) and I found it put my site at the mercy of intensedebate's server speed and availability. It tended to slow everything down. Maybe DisQus is better; I guess we'll find out.
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. ;)
If my plans go well, we'll have each project in a separate Git repo soon. The consequences are not all known, but one reasonably likely scenario is that we'll want to switch from Trac to something else (e.g. Redmine), so be wary about investing *too* much effort in trac-related stuff too early.
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.
I think web forums like BBPress support a mailing-list-like experience, don't they? I'd really like to see lightweight subscribable discussion topic areas.
Thanks for reading this far, comments, suggestions, reactions, and pledges to help would be greatly appreciated.
I'll am focused on the ryppl side of things, but I hope we'll coordinate and cooperate. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
I've been following this discussion with some interest. I feel it's moving in the right direction. There is one thing I wonder/worry about. I've created a couple of interactive websites from time to time. It has been sometime since I've done so, so I'm way out of date with the latest tools and techniques. I created these sites with relatively simple cgi scripts written in perl. These two sites were created about 15 years ago and have worked without problem for all that time. I've had to make a few tweaks every couple of years to keep things humming. So although not as "slick" as many current options, they have low maintainence and provide all the functionality I require. This is bottom line for me. In the intervening time, there have been a myriad of tools created to do this job "better". Also the number of libraries available as perl scripts is much, much larger. I've experimented with other method such as FrontPage, ASP, very occasionally to see if I was missing something. The only thing that I think I might use if I were to do this again is javascript. 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. 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. 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. At that point, I sketched out something that could be done without amending www.boost.org. But now that this cat is out of the bag, I'll offer my two cents. www.boost.org pages about boost ( basically static pages) history practices procedures .... library index Review/accepted libraries Alphabetical list links to library pages By subject links to library pages Submitted/accepted candidate libraries Alphabetical list links to library pages By subject links to library pages Each library page - similar to what I presented as an example - see http://www.rrsd.com/software_development/boost/BoostCon2010/library_status.h... 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. The lack of a "unified" system will be found to be off putting to some - but this methods lets Boost evolve as necessary. Robert Ramey
On 26 May 2010 18:08, Robert Ramey <ramey@rrsd.com> wrote:
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.
It just uses php and htaccess, which are not at all fancy. The implementation is complicated in places but I wouldn't describe it as hard to extend. Daniel
On Thu, May 27, 2010 at 1:08 AM, Robert Ramey <ramey@rrsd.com> 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.h... 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
Dean Michael Berris wrote:
On Thu, May 27, 2010 at 1:08 AM, Robert Ramey <ramey@rrsd.com> wrote:
The VCR mentality has spread like a cancer.
Okay, but Robert this is a generalization.
I admit I have my prejudices. There is one thing. The person who does the work gets to decide how to do it. This is not so much as statement of equity - but actually a statement of fact. Good luck to anyone who takes this on. I'm sure everyone will be want to give a fair shot.
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 issue tracking, patches, proposed enhacements - discussions (?) complaints, reviews, etc. - static pages (FAQ, History, etc.)
That looks close enough for government work.
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%.
One thing that I believe is that each developer should be able to select the build, test and deployment system(s) he want's to support. For many simple libraries which are header only, a simple makefile to build and run all the tests is all that is needed. Likewise, a simple zip file is sufficient for deployment. While others need something more elaborate. So I would like to defer these decisions to the developer. This would make the web design/deployment, etc job smaller. It would let ideas like rypll enter into the mix one library at a time. On the other hand, I like the idea of a common look and feel - like google search pages. That way everything is where I expect to find it and it's easier to make comparisons. I hate it when every one has their "cute" feature - like a 50MB rap video extolling the virtues of their library. or whatever. This is perhaps too far ahead at this point - but I can't resist the opportuntity to tell someone else how to do his job. Robert Ramey
On Wed, May 26, 2010 at 8:05 PM, David Abrahams <dave@boostpro.com> wrote:
At Wed, 26 May 2010 10:49:11 +0800, Dean Michael Berris wrote:
Step 1: Move static and not-so-static content over to Wordpress MU [0]
Yay. Consider also whether you want to go a little further, to buddypress. Also consider that WP 3.0 is imminent and it is supposed to include all the MU functionality natively.
Thanks for the pointers -- buddypress seems to be more geared towards a social network feel, which I'm not entirely sure would be something that I'd be willing to manage at this time. Although it would be interesting to have a dashboard when people sign in on what's going on with what they're interested in, that's certainly an option. I can experiment with buddypress offline and see whether I can adjust my expectations and plan of action as soon as I get a better feel of what buddypress can offer that would be valuable to the community.
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).
The WYSIWYG editor has an “HTML face,” so there's no need to retype anything.
Yup, but then I'd have to still check whether the structure and the content translate well to the new platform. You know how it can be with HTML and CSS. ;)
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.
My only reservation is that I tried a similar plugin (http://wordpress.org/extend/plugins/intensedebate/) and I found it put my site at the mercy of intensedebate's server speed and availability. It tended to slow everything down. Maybe DisQus is better; I guess we'll find out.
So far, DisQus has been the leader in the comment-hosting field -- they're being used by the big enough blogs that generate insane traffic. They're cloud-hosted and grow on demand last time I checked, and I've had no problems with them yet. The worst case scenario would be that we host the comments, which might not be the best use of (limited) resources we have on the server that's going to be hosting the site.
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. ;)
If my plans go well, we'll have each project in a separate Git repo soon. The consequences are not all known, but one reasonably likely scenario is that we'll want to switch from Trac to something else (e.g. Redmine), so be wary about investing *too* much effort in trac-related stuff too early.
Yup, that's alright. Links at the very least should work fine in the interim. If there's going to be any more work besides adding links in the appropriate places then I'll hold that off for later. :)
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.
I think web forums like BBPress support a mailing-list-like experience, don't they? I'd really like to see lightweight subscribable discussion topic areas.
Yes (although I can't check at the moment, BBPress' site seems to be having problems). I'll look deeper into it. At the very least RSS per topic/thread should be available and AFAIK would be standard in reasonably modern bulletin board systems.
Thanks for reading this far, comments, suggestions, reactions, and pledges to help would be greatly appreciated.
I'll am focused on the ryppl side of things, but I hope we'll coordinate and cooperate.
Definitely hope coordinate and cooperate as things go along. :) -- Dean Michael Berris deanberris.com
On 5/26/2010 9:01 PM, Dean Michael Berris wrote:
So far, DisQus has been the leader in the comment-hosting field -- they're being used by the big enough blogs that generate insane traffic. They're cloud-hosted and grow on demand last time I checked, and I've had no problems with them yet. The worst case scenario would be that we host the comments, which might not be the best use of (limited) resources we have on the server that's going to be hosting the site.
I should point out that the original, which was partially working, had comments hosted by us. At the time I searched for a non-self-hosted solution but the commenting tools field was essentially non-existent at the time.
Yes (although I can't check at the moment, BBPress' site seems to be having problems). I'll look deeper into it. At the very least RSS per topic/thread should be available and AFAIK would be standard in reasonably modern bulletin board systems.
In case it's not obvious.. Many people here prefer the mail list for most stuff. Since I use a few other development web forums, I still prefer mail lists. But there are advantages to web forums, StackOverflow being one of the few successful designs I've seen. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
----- Original Message ----- From: "David Abrahams" <dave@boostpro.com> To: <boost@lists.boost.org> Sent: Wednesday, May 26, 2010 2:05 PM Subject: Re: [boost] [proposal] The boost.org Maintenance Effort
* 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.
I think web forums like BBPress support a mailing-list-like experience, don't they? I'd really like to see lightweight subscribable discussion topic areas.
-- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, May 25, 2010 at 10:49 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
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]
I know nothing about Wordpress, so it is difficult for me to evaluate your proposal. Could you point me to a website that uses Wordpress in a way that is similar to what you are proposing? I'd like to see the administrative interface as well as the public facade. Are any of the Wordpress tutorials or video tutorials worth watching? Which ones? --Beman
On Wed, May 26, 2010 at 8:13 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, May 25, 2010 at 10:49 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
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]
I know nothing about Wordpress, so it is difficult for me to evaluate your proposal. Could you point me to a website that uses Wordpress in a way that is similar to what you are proposing? I'd like to see the administrative interface as well as the public facade.
Although technically hosted on wordpress.com (where you can also sign up for a blog so you can mess around with it at your own pace), you can go check gigaom.com and techcrunch.com -- they have a network of blogs that have their own communities. Also, thisweekin.com is a wordpress installation, and have different sub-sites for different shows, each with their own communities.
Are any of the Wordpress tutorials or video tutorials worth watching? Which ones?
Definitely, and wordpress.tv is the place to go for screencasts and videos highlighting the ways you can do things with wordpress. It's also really easy to set-up on a Linux machine and start messing around with it. HTH -- Dean Michael Berris deanberris.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Dean Michael Berris Sent: Thursday, May 27, 2010 3:09 AM To: boost@lists.boost.org Subject: Re: [boost] [proposal] The boost.org Maintenance Effort
It's also really easy to set-up on a Linux machine and start messing around with it.
Ah - but is it easy to use on *all* the various platforms? Previous documentation systems have proved most unsatisfactory because they only worked on one platform. Only the original author could make modifications. Wiki and Quickbook work because they only require the simplest of text editor and a slight amount of knowledge. Keep It Simple Sir! Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
On 27 May 2010 09:28, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
It's also really easy to set-up on a Linux machine and start messing around with it.
Ah - but is it easy to use on *all* the various platforms?
I've been running wordpress on windows server for a while. It's not as good as linux but it has improved considerably over the last few years. Some plugins do have issues, but that's getting better. I basically just upgrade it when required and leave it to run itself. Microsoft has an automatic installer, although I've never tried it: http://www.microsoft.com/web/gallery/WordPress.aspx If you just want to try a local install, you could try using xampp which sets up apache, mysql and php for you, google 'wordpress xampp'. Daniel
On Thu, May 27, 2010 at 4:28 PM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Dean Michael Berris Sent: Thursday, May 27, 2010 3:09 AM To: boost@lists.boost.org Subject: Re: [boost] [proposal] The boost.org Maintenance Effort
It's also really easy to set-up on a Linux machine and start messing around with it.
Ah - but is it easy to use on *all* the various platforms?
But you don't need to run Wordpress on your own machine to make modifications to the Wordpress installation on the boost.org server. If you want to mess around with Wordpress, then you can install it on your machine. This has nothing to do with boost.org being hosted on a Wordpress installation.
Previous documentation systems have proved most unsatisfactory because they only worked on one platform.
Only the original author could make modifications.
Wiki and Quickbook work because they only require the simplest of text editor and a slight amount of knowledge.
Yes, and I haven't proposed to change the Wiki or the use of Quickbook in documentation. I think you're missing the point here. Wordpress is going to be used on the server side to host the website. Documentation will still be generated "the normal way" either hosted on the Wiki or from Quickbook or RST to form HTML that's hosted on the server as well. I -- or for that matter, anyone with the privileges -- can edit pages on the Wordpress installation without requiring a Wordpress installation on their local machine. You just need a sufficiently modern browser that can handle HTML and Javascript to do so.
Keep It Simple Sir!
If you haven't checked out Wordpress yet, it is Simple as Simple can be. Please Read The Fine Manual Sir! -- Dean Michael Berris deanberris.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Dean Michael Berris Sent: Thursday, May 27, 2010 1:31 PM To: boost@lists.boost.org Subject: Re: [boost] [proposal] The boost.org Maintenance Effort
Wordpress is going to be used on the server side to host the website. Documentation will still be generated "the normal way" either hosted on the Wiki or from Quickbook or RST to form HTML that's hosted on the server as well.
I -- or for that matter, anyone with the privileges -- can edit pages on the Wordpress installation without requiring a Wordpress installation on their local machine. You just need a sufficiently modern browser that can handle HTML and Javascript to do so.
OK That sounds a low enough common denominator - the main point of my warning.
Keep It Simple Sir!
If you haven't checked out Wordpress yet, it is Simple as Simple can be.
Please Read The Fine Manual Sir!
OK - Touche! Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
On Thu, May 27, 2010 at 9:16 PM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Dean Michael Berris Sent: Thursday, May 27, 2010 1:31 PM To: boost@lists.boost.org Subject: Re: [boost] [proposal] The boost.org Maintenance Effort
[snip]
I -- or for that matter, anyone with the privileges -- can edit pages on the Wordpress installation without requiring a Wordpress installation on their local machine. You just need a sufficiently modern browser that can handle HTML and Javascript to do so.
OK That sounds a low enough common denominator - the main point of my warning.
I actually appreciate you pointing it out, it may have caused some confusion with others not familiar with Wordpress too. :)
Keep It Simple Sir!
If you haven't checked out Wordpress yet, it is Simple as Simple can be.
Please Read The Fine Manual Sir!
OK - Touche!
:D -- Dean Michael Berris deanberris.com
On Wed, May 26, 2010 at 10:08 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Wed, May 26, 2010 at 8:13 PM, Beman Dawes <bdawes@acm.org> wrote:
I know nothing about Wordpress, so it is difficult for me to evaluate your proposal. Could you point me to a website that uses Wordpress in a way that is similar to what you are proposing? I'd like to see the administrative interface as well as the public facade.
Although technically hosted on wordpress.com (where you can also sign up for a blog so you can mess around with it at your own pace), you can go check gigaom.com and techcrunch.com -- they have a network of blogs that have their own communities. Also, thisweekin.com is a wordpress installation, and have different sub-sites for different shows, each with their own communities.
Those are interesting from the standpoint of library developers who wants to set up blogs and develop their own communities. That's important for some libraries, but... What about the developer (me, for example, and the filesystem library) who doesn't want a blog, doesn't want to develop a separate community, and prefers to continue to use the main boost mailing list for discussions. Would I have to do anything different? In particular, would any aspect the HTML files in boost-root/libs/filesystem/doc change? Can I continue to use plain-old-HTML and my old WYSIWYG HTML editor? If I wanted to make my doc pages more consistent with the rest of Boost, would there be style sheets available that my old WYSIWYG HTML editor could use? If I wanted to upgrade to a more modern desktop WYSIWYG HTML editor, does Wordpress supply one? One of the frustrations with trying to understand Wordpress is that everything Google finds has to do with online use of a Wordpress web site. Does Wordpress have no tools for regular offline desktop WYSIWYG HTML editing?
It's also really easy to set-up on a Linux machine and start messing around with it.
I'm primarily a Windows user. --Beman
At Thu, 27 May 2010 10:48:18 -0400, Beman Dawes wrote:
What about the developer (me, for example, and the filesystem library) who doesn't want a blog, doesn't want to develop a separate community, and prefers to continue to use the main boost mailing list for discussions.
Would I have to do anything different? In particular, would any aspect the HTML files in boost-root/libs/filesystem/doc change?
I think, as long as you phrase it so broadly, the answer is likely “yes.” For example, I imagine that the presentation of those files on the website might change a little.
Can I continue to use plain-old-HTML and my old WYSIWYG HTML editor?
We *can't* make a system that doesn't support those formats, or we wouldn't be able to serve tons of existing documentation.
If I wanted to make my doc pages more consistent with the rest of Boost, would there be style sheets available that my old WYSIWYG HTML editor could use?
Clearly, yes.
If I wanted to upgrade to a more modern desktop WYSIWYG HTML editor, does Wordpress supply one?
No; wordpress doesn't do applications. Well, that's not quite true; they do applications for mobile devices. What they do for desktop users who don't like the web interface is that they supply an XML-RPC API that allows other applications to interact with the site. Wordpress being the dominant blogging software (in fact, I have heard that 8% of all websites are WP-based), the API is well supported by many such tools. Being an emacs weenie, of course I edit my blog content in emacs and press the magic key combo that publishes it.
One of the frustrations with trying to understand Wordpress is that everything Google finds has to do with online use of a Wordpress web site. Does Wordpress have no tools for regular offline desktop WYSIWYG HTML editing?
That's out of scope for WP. If you want to edit HTML offline on your desktop there are plenty of good applications out there. It wouldn't make sense for WP to maintain a another desktop HTML editor just so it could interface with WP sites. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
On Fri, May 28, 2010 at 9:23 AM, David Abrahams <dave@boostpro.com> wrote:
At Thu, 27 May 2010 10:48:18 -0400, Beman Dawes wrote:
What about the developer (me, for example, and the filesystem library) who doesn't want a blog, doesn't want to develop a separate community, and prefers to continue to use the main boost mailing list for discussions.
Would I have to do anything different? In particular, would any aspect the HTML files in boost-root/libs/filesystem/doc change?
I think, as long as you phrase it so broadly, the answer is likely “yes.” For example, I imagine that the presentation of those files on the website might change a little.
Mostly the headers and the CSS would change to be consistent with the new system. However they will remain to be HTML files generated the same way.
Can I continue to use plain-old-HTML and my old WYSIWYG HTML editor?
We *can't* make a system that doesn't support those formats, or we wouldn't be able to serve tons of existing documentation.
The answer is yes, you can continue to do HTML as long as you're willing to do so. ;-)
One of the frustrations with trying to understand Wordpress is that everything Google finds has to do with online use of a Wordpress web site. Does Wordpress have no tools for regular offline desktop WYSIWYG HTML editing?
That's out of scope for WP. If you want to edit HTML offline on your desktop there are plenty of good applications out there. It wouldn't make sense for WP to maintain a another desktop HTML editor just so it could interface with WP sites.
The reason the only thing Google finds about Wordpress editing requires an online installation of Wordpress is that it's the only way that makes sense for managing a Wordpress installation. It's not a documentation system (like Sphinx or Jekyll or Hyde or Quickbook) but it's a publishing system. It just so happens to have a very nice WYSIWYG editor that works from within a browser. Dave is actually right that this is out of scope for Wordpress -- it's a publishing platform that is meant to make online publishing easy. That assumes you have an existing place to publish to, and that's also where you would generally input your content. Like Dave suggested, Wordpress has an API that other tools are already integrating with. If you *really* want to do desktop-based publishing on Windows you might want to try Windows Live Writer [0] -- which is meant to manage blogs that are hosted in most of the popular blogging platforms. Last time I checked it has great support for Wordpress. If you are just thinking about writing library documentation, you can go about the current process with little to no change in the process -- if you write Quickbook, RST, or plain HTML, that should be just fine. Just be prepared to support a new stylesheet when the time comes to migrate to the new look & feel. HTH [0] http://windowslivewriter.spaces.live.com/ -- Dean Michael Berris deanberris.com
On Thu, May 27, 2010 at 11:08 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
If you are just thinking about writing library documentation, you can go about the current process with little to no change in the process
Good!
-- if you write Quickbook, RST, or plain HTML, that should be just fine. Just be prepared to support a new stylesheet when the time comes to migrate to the new look & feel.
That shouldn't be a problem, at least for simple stylesheets. The key point being that it would be great to upgrade the website, but gets sticky if there is much impact on how developers work. --Beman
At Fri, 28 May 2010 14:44:09 -0400, Beman Dawes wrote:
-- if you write Quickbook, RST, or plain HTML, that should be just fine. Just be prepared to support a new stylesheet when the time comes to migrate to the new look & feel.
That shouldn't be a problem, at least for simple stylesheets.
The key point being that it would be great to upgrade the website, but gets sticky if there is much impact on how developers work.
“are forced to”--------------------------------------^ I really hope Dean's efforts have a huge impact on how developers work. By choice. :-) -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
On Fri, May 28, 2010 at 2:53 PM, David Abrahams <dave@boostpro.com> wrote:
At Fri, 28 May 2010 14:44:09 -0400, Beman Dawes wrote:
-- if you write Quickbook, RST, or plain HTML, that should be just fine. Just be prepared to support a new stylesheet when the time comes to migrate to the new look & feel.
That shouldn't be a problem, at least for simple stylesheets.
The key point being that it would be great to upgrade the website, but gets sticky if there is much impact on how developers work.
“are forced to”--------------------------------------^
Right! --Beman
Dean Michael Berris wrote:
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.
All reasonable and, to some degree or other, already satisfied.
Participation
* Let's encourage participation in the form of comments to blog posts, feedback on documentation pages, and discussions on specific topics/threads.
It is already painful to keep up with all of the different places where people choose to post information. Do we really need more? I'm wary of the fragmentation that this could engender, but perhaps the user side of Boost would benefit most from this change.
* 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.
A nice idea.
* 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.
Nice.
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.
This sounds like fragmentation and, therefore, is worrisome. Is it truly helping to add yet more places one must search to find information relevant to an issue or question? If boost-users were replaced by this mechanism, it might be practicable.
* Let's foster a more community-driven way of solving problems without having to require everyone to be part of a central list.
The lists can be off-putting, to be sure. Greater segregation is useful but it leads to information silos.
* Let's allow communities around Boost libraries to grow and get things done on the boost.org website.
Building library-specific communities is a good idea.
Step 1: Move static and not-so-static content over to Wordpress MU [0]
Like Beman, I really don't know what that means in terms of appearance, layout, navigation, or management.
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.
The web site certainly needs a feedback mechanism. I have no comment on the appropriate tool for the job.
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.
Comments for blog posts, doc pages, etc., could be useful. Does DisQus handle the spam issue?
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.
I suppose this is to gauge popularity of libraries or specific pages?
Step 2: Make it easy to jump from Wordpress MU to Trac for the Wiki, Tickets, and Source Viewer
It goes without saying that all web content must be well integrated.
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).
I'd agree that all libraries should have this, even if only as a place for release managers to post something.
* 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.
+1
* 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.
+1
* 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.
This is certainly necessary. If each documentation page were served separately with a comments section, then documentation comments could be managed away from the developer's list.
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.
A number of your suggestions seem contrary to this affirmation of the list(s). _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
At Wed, 26 May 2010 09:19:05 -0400, Stewart, Robert wrote:
Participation
* Let's encourage participation in the form of comments to blog posts, feedback on documentation pages, and discussions on specific topics/threads.
It is already painful to keep up with all of the different places where people choose to post information. Do we really need more? I'm wary of the fragmentation that this could engender, but perhaps the user side of Boost would benefit most from this change.
One point in favor: Google “likes” blogs.
* Let's foster a more community-driven way of solving problems without having to require everyone to be part of a central list.
The lists can be off-putting, to be sure. Greater segregation is useful but it leads to information silos.
Not if you do it right. With a hierarchical forum you can be subscribed to everything or get very specific.
* Let's allow communities around Boost libraries to grow and get things done on the boost.org website.
Building library-specific communities is a good idea.
Step 1: Move static and not-so-static content over to Wordpress MU [0]
Like Beman, I really don't know what that means in terms of appearance, layout, navigation, or management.
It could mean anything in terms of appearance, layout, and navigation. But it starts with a site structure that many people are already comfortable with.
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.
Comments for blog posts, doc pages, etc., could be useful. Does DisQus handle the spam issue?
WP-SpamFree does that. (Google it). -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
On Wed, May 26, 2010 at 9:19 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Dean Michael Berris wrote:
Participation
* Let's encourage participation in the form of comments to blog posts, feedback on documentation pages, and discussions on specific topics/threads.
It is already painful to keep up with all of the different places where people choose to post information. Do we really need more? I'm wary of the fragmentation that this could engender, but perhaps the user side of Boost would benefit most from this change.
I think the word "fragmentation" unnecessarily denotes a negative meaning. I don't think fragmentation is necessarily bad -- the idea that the Boost community would grow does not preclude the idea of having little sub-communities within the larger Boost community. If you think about it, Boost.Spirit already has a thriving community which I personally think is still part of the Boost community. I don't think it's a bad idea to have more of these communities coming up and furthering the Boost "brand". I just think it should really be easy for communities to form around a certain library and putting it all on the web is one of the easiest ways of doing it. One thing that has been discussed and that has been proposed is to de-couple the boost libraries and let each one thrive on its own, getting the seal of Boost Approval in the form of inclusion in the main Boost distribution. I don't see why individual library maintainers shouldn't strive for building communities around their own libraries in an easy manner.
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.
This sounds like fragmentation and, therefore, is worrisome. Is it truly helping to add yet more places one must search to find information relevant to an issue or question? If boost-users were replaced by this mechanism, it might be practicable.
I'm not going to propose the removal of the mailing lists. This is the reason why: Technically, the wealth of content we can generate for the web will largely come from discussions that happen on the mailing lists. We can hash out ideas, float solutions, pose questions, etc. on the mailing lists (both user and developer lists) and then have someone recap and bring the discussion to the attention of the larger web (i.e. Google, Bing, Yahoo) so that it can be indexed properly, slashdotted, dugg, linked to on stackoverflow.com, reddit'ed, facebooked, twittered, and <insert viral distribution channel here>. That someone can be me or some other administrator or library maintainer or even a volunteer who would write it up and be willing to submit it to the website. There is no fragmentation there, and the discussion that happens on the website can be a different nature too, which can be continued in the developers list and the users list, and then later updated when a resolution is found. If it comes up enough often an update to the FAQ can be done on the individual library or issue being discussed.
* Let's foster a more community-driven way of solving problems without having to require everyone to be part of a central list.
The lists can be off-putting, to be sure. Greater segregation is useful but it leads to information silos.
Unfortunately, in the end, whatever silo you put it to but as long as Google can get to it, it's the one silo that really matters. Well for bing fans, that's another silo too. ;)
Step 1: Move static and not-so-static content over to Wordpress MU [0]
Like Beman, I really don't know what that means in terms of appearance, layout, navigation, or management.
Fair enough, I invite you to wordpress.tv to take a look-see on what is possible and what is already being done with wordpress. (I'm starting to sound like a Wordpress evangelist! :D).
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.
Comments for blog posts, doc pages, etc., could be useful. Does DisQus handle the spam issue?
Yes, and they also allow users to use their Facebook, Twitter, or Google id's (including other OpenID providers) to comment. No need to sign up for a special DisQus account to make it happen. DisQus also has a great administration interface which allows administrators to mark posts as spam to improve DisQus' spam filtering efforts.
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.
I suppose this is to gauge popularity of libraries or specific pages?
Not really, but just for general information. Anybody can read whatever they want into analytics reports, but that's really largely just a matter of interpretation. Having the reports is key though so people can make informed decisions on whether to write something up, start promoting more (of if they promoted something, whether that promotion actually did something), etc.
* 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.
This is certainly necessary. If each documentation page were served separately with a comments section, then documentation comments could be managed away from the developer's list.
This can actually be done with DisQus.
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.
A number of your suggestions seem contrary to this affirmation of the list(s).
Maybe so if you look at fragmentation as a bad thing. If there's more communities for the Boost umbrella to cover, then I'd say that's growth of the Boost community -- instead of being just one big monolithic community, be comprised of a lot of smaller communities. To me, that is a more scalable way of growing Boost than what currently is happening. HTH -- Dean Michael Berris deanberris.com
At Thu, 27 May 2010 10:30:11 +0800, Dean Michael Berris wrote:
On Wed, May 26, 2010 at 9:19 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Dean Michael Berris wrote:
Participation
* Let's encourage participation in the form of comments to blog posts, feedback on documentation pages, and discussions on specific topics/threads.
It is already painful to keep up with all of the different places where people choose to post information. Do we really need more? I'm wary of the fragmentation that this could engender, but perhaps the user side of Boost would benefit most from this change.
I think the word "fragmentation" unnecessarily denotes a negative meaning. I don't think fragmentation is necessarily bad -- the idea that the Boost community would grow does not preclude the idea of having little sub-communities within the larger Boost community. If you think about it, Boost.Spirit already has a thriving community which I personally think is still part of the Boost community. I don't think it's a bad idea to have more of these communities coming up and furthering the Boost "brand". I just think it should really be easy for communities to form around a certain library and putting it all on the web is one of the easiest ways of doing it.
Furthermore, IMO, a model where boost grows without sub-communities is unsustainable. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
participants (9)
-
Beman Dawes -
Daniel James -
David Abrahams -
Dean Michael Berris -
Paul A. Bristow -
Rene Rivera -
Robert Ramey -
Stewart, Robert -
vicente.botet