Re: Issue #2 - Allow contributions to website from browser

The way one can contribute to SPI's website is explained on http://www.spi-inc.org/ :

> This website is managed using ikiwiki+git. You can view the revision history via gitweb <http://git.spi-inc.org/gitweb/?p=website.git> and send any updates, either as a git pull request or a patch, to webmaster(at)spi-inc(dot)org <mailto:webmaster(at)spi-inc(dot)org>.

Contributions would be much more appealing if there was a more intuitive way to modify, in particular for casual contributors. The web interface provided by a wiki or web content management system would provide such an appeal. This is a wide request which does not demand any particular wiki or CMS. Such a system could replace the current website or supplement it, consisting only of new pages.

Wikis often use an engine-specific markup language to store page contents. One wiki engine which does that and whose language already benefits from an important diffusion among potential contributors is MediaWiki. MediaWiki allows contributors to propose a new version of a page which then needs to be approved before publication, but only with the FlaggedRevs extension. MediaWiki is unfortunately not in Debian testing currently. Drupal is another option, which is in Debian testing.

This does not request any specific authorizations. Pages could use the soft security of open wikis, be only editable by SPI members, require approval by a team, or a mix of all of these policies depending on the topic.

--
Filipus Klutiero
http://www.philippecloutier.com

On Sun, Aug 14, 2016 at 11:05:22AM -0400, Filipus Klutiero wrote:
> The way one can contribute to SPI's website is explained on
> http://www.spi-inc.org/ :
>
> >This website is managed using ikiwiki+git. You can view the revision
> >history via gitweb <http://git.spi-inc.org/gitweb/?p=website.git> and
> >send any updates, either as a git pull request or a patch, to
> >webmaster(at)spi-inc(dot)org <mailto:webmaster(at)spi-inc(dot)org>.
>
> Contributions would be much more appealing if there was a more
> intuitive way to modify, in particular for casual contributors. The
> web interface provided by a wiki or web content management system
> would provide such an appeal. This is a wide request which does not
> demand any particular wiki or CMS. Such a system could replace the
> current website or supplement it, consisting only of new pages.

Contributions to the SPI website went up significantly by moving from
Plone to ikiwiki, and the website became much more current. Empirical
evidence thus suggests we're much better off where we currently are.
Based on experience managing a number of wikis I think the workload
involved in helping people who want to contribute at present but can't
deal with ikiwiki is significantly lower than dealing with an open (or
even approval based) wiki or CMS.

J.

--
"I put it down to corrosive groin sweat myself." -- John Burnham, asr

* Jonathan McDowell <noodles(at)earth(dot)li> [2016-08-14 21:25]:
> Contributions to the SPI website went up significantly by moving from
> Plone to ikiwiki, and the website became much more current. Empirical
> evidence thus suggests we're much better off where we currently are.
> Based on experience managing a number of wikis I think the workload
> involved in helping people who want to contribute at present but can't
> deal with ikiwiki is significantly lower than dealing with an open (or
> even approval based) wiki or CMS.

Agreed.

We're definitely open to contributors but we don't use a CMS and
despite using ikiwiki the web site is also not a wiki. SPI's web site
is a static web site generated with ikiwiki from Markdown. You also
cannot edit debian.org directly, for example, but contributions are
welcome. Same with SPI. The git repository is available (there's a
link from the front page) and you're welcome to send patches or pull
requests. The webmaster email is also displayed for those wanting to
provide feedback.

If someone makes sustained contributions, I'm sure we'd be happy to
give direct access to the git repo.

--
Martin Michlmayr
http://www.cyrius.com/

On 2016-08-14 16:25, Jonathan McDowell wrote:
> On Sun, Aug 14, 2016 at 11:05:22AM -0400, Filipus Klutiero wrote:
>> The way one can contribute to SPI's website is explained on
>> http://www.spi-inc.org/ :
>>
>>> This website is managed using ikiwiki+git. You can view the revision
>>> history via gitweb <http://git.spi-inc.org/gitweb/?p=website.git> and
>>> send any updates, either as a git pull request or a patch, to
>>> webmaster(at)spi-inc(dot)org <mailto:webmaster(at)spi-inc(dot)org>.
>> Contributions would be much more appealing if there was a more
>> intuitive way to modify, in particular for casual contributors. The
>> web interface provided by a wiki or web content management system
>> would provide such an appeal. This is a wide request which does not
>> demand any particular wiki or CMS. Such a system could replace the
>> current website or supplement it, consisting only of new pages.
> Contributions to the SPI website went up significantly by moving from
> Plone to ikiwiki, and the website became much more current.

Many thanks Jonathan; I had forgotten SPI previously used Plone. The Wayback machine shows that we switched from Plone to Ikiwiki in Q4 2010, but a quick search on Google did not find an analysis of that change, either anterior or posterior.

> Empirical
> evidence thus suggests we're much better off where we currently are.

I don't remember ever contributing to a Plone website. I have no idea why the switch was made and whether it was beneficial, but I did not mean at all to suggest reverting it.

> Based on experience managing a number of wikis I think the workload
> involved in helping people who want to contribute at present but can't
> deal with ikiwiki is significantly lower than dealing with an open (or
> even approval based) wiki or CMS.

I am not sure what you meant exactly by "deal", but recruitment of contributors unable to *use* the current system is not the main benefit I see. I was rather seeing a switch as a way to make contributing more appealing.

As for the workload involved in dealing with wikis or CMS-s, were you referring to content administration?

--
Filipus Klutiero
http://www.philippecloutier.com

On 2016-08-14 21:27, Martin Michlmayr wrote:
> * Jonathan McDowell <noodles(at)earth(dot)li> [2016-08-14 21:25]:
>> Contributions to the SPI website went up significantly by moving from
>> Plone to ikiwiki, and the website became much more current. Empirical
>> evidence thus suggests we're much better off where we currently are.
>> Based on experience managing a number of wikis I think the workload
>> involved in helping people who want to contribute at present but can't
>> deal with ikiwiki is significantly lower than dealing with an open (or
>> even approval based) wiki or CMS.
> Agreed.
>
> We're definitely open to contributors but we don't use a CMS and
> despite using ikiwiki the web site is also not a wiki. SPI's web site
> is a static web site generated with ikiwiki from Markdown.

Thank you Martin.

> You also
> cannot edit debian.org directly, for example, but contributions are
> welcome. Same with SPI.

Debian's situation is far from perfect despite important advances, but it is better than SPI's in a number of important ways. Specifically about the possibility to edit directly, while you are right if focusing on www.debian.org, that is not the case with wiki.debian.org, which would be approximately as important as www.debian.org, despite being quite newer.

> The git repository is available (there's a
> link from the front page) and you're welcome to send patches or pull
> requests. The webmaster email is also displayed for those wanting to
> provide feedback.
>
> If someone makes sustained contributions, I'm sure we'd be happy to
> give direct access to the git repo.
>

While having to learn a new syntax is already quite a disadvantage, at least for me, having to send patches to an opaque system whose performance I cannot evaluate multiplies my hesitation. Knowing that a direct access would come would help, but only those who will make sustained contributions and who already know they will. If you meant to encourage contribution, I am not the person to address. Experience has taught me not to contribute in such conditions. Putting such a statement on the website *might* help.

--
Filipus Klutiero
http://www.philippecloutier.com

Filipus Klutiero <chealer(at)gmail(dot)com> writes:

> While having to learn a new syntax is already quite a disadvantage, at
> least for me

It is for all of us... which is exactly why we moved to the ikiwiki+git
combination... because at least at the time it used technology and
skills that all of the board members were comfortable with, and enabling
ourselves to be able to more easily contribute to the web content was a
higher priority than enabling "others" who might not have the same
skills to do so.

It's entirely possible to enable in-place editing of ikiwiki content
through a browser interface, retaining the git revision control back
end. There are some security implications for enabling this
functionality, as there is with just about any web-server based access
mechanism. Whether the SPI admin team thinks they are acceptable risks
is something only they can answer.

Frankly, though, the fact that anyone can install the ikiwiki processor
locally and apply it to a checked out copy of the web content git
repository means that it may just be a better plan to assume that anyone
who wants to contribute will be willing to "figure things out"...

Bdale

On 08/18/2016 07:53 PM, Bdale Garbee wrote:

> Frankly, though, the fact that anyone can install the ikiwiki processor
> locally and apply it to a checked out copy of the web content git
> repository means that it may just be a better plan to assume that anyone
> who wants to contribute will be willing to "figure things out"...

Comments like this essentially equate to:

SPI in its current incarnation is a great silo for a lot of really smart
people who face each other saying, "we know best" while everyone else
drives by the farm.

While I was still on Board. I was asked to update my contact
information. I had to:

* Supply a ssh key
* Learn the basic configuration (URL etc...) of the SPI git repository
* Deal with an acrimonious board member because I misread the url
* Remember my basic git commands (I use it maybe once/twice a year
outside of a git clone/git diff)
* Edit a *TEXT FILE* that contained contact information

This is not 1982. This should *all* be in a CMS/CRM, backed to a proper
database (PostgreSQL ;)). The information should be a part of my
membership profile. I should (at the time) be a member of the "board" role.

I just joined OpenSource.org (literally). They use CiviCRM. Looking
objectively at their site, I have learned more about Open
Source/FreeSoftware, Community, Licensing, Contributing and events than
I learned in the entire time I have a been a member of SPI.

I wonder if they have these same issues or if they realized like most of
the productive world that at some point you compromise for the larger goal.

Sincerely,

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.

On Fri, Aug 19, 2016 at 07:40:49AM -0700, Joshua D. Drake wrote:
> I just joined OpenSource.org (literally). They use CiviCRM. Looking
> objectively at their site, I have learned more about Open
> Source/FreeSoftware, Community, Licensing, Contributing and events
> than I learned in the entire time I have a been a member of SPI.
>
> I wonder if they have these same issues or if they realized like most
> of the productive world that at some point you compromise for the
> larger goal.

Speaking as a OSI board member (but of course not for the organization
as a whole): we've had so many issues and lost^W invested so much time
in dealing with CiviCRM quirks, that I would trade it with literally
anything else any day.

To be fair though, the content (as opposed to membership management) of
our main website is in plain Drupal, which has served us pretty well. It
has also made it easy to find both volunteers and contractors to develop
a new theme.

The only bottom line here is that you should optimize for the work force
you've at your disposal---be it volunteers or contractors. SPI had
"geeky" people power available and optimized for that. That seems to
have served the organization quite well: both the website and membership
management had been dead for a very long time in the Plone days, with
nobody willing to touch the thing with a ten foot pole, before the
technical revamp that happened in recent years after the switch to
something else.

Cheers.
--
Stefano Zacchiroli . zack(at)upsilon(dot)cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

On 08/19/2016 08:12 AM, Stefano Zacchiroli wrote:
> On Fri, Aug 19, 2016 at 07:40:49AM -0700, Joshua D. Drake wrote:
>> I just joined OpenSource.org (literally). They use CiviCRM. Looking
>> objectively at their site, I have learned more about Open
>> Source/FreeSoftware, Community, Licensing, Contributing and events
>> than I learned in the entire time I have a been a member of SPI.
>>
>> I wonder if they have these same issues or if they realized like most
>> of the productive world that at some point you compromise for the
>> larger goal.
>
> Speaking as a OSI board member (but of course not for the organization
> as a whole): we've had so many issues and lost^W invested so much time
> in dealing with CiviCRM quirks, that I would trade it with literally
> anything else any day.

FTR: I was not endorsing CiviCRM vs $INSERT-TECH here.

>
> To be fair though, the content (as opposed to membership management) of
> our main website is in plain Drupal, which has served us pretty well. It
> has also made it easy to find both volunteers and contractors to develop
> a new theme.

Yeah, Drupal for all its quirks is a pretty decent platform. PgUS uses
Drupal and the ability to manage pretty much everything point in click
allows us to focus on what the corporation is actually there for. For
us, the only real downside was we got bit by the 5->6-7 problem but
those problems don't exist for newer versions (they learned).

>
> The only bottom line here is that you should optimize for the work force
> you've at your disposal---be it volunteers or contractors. SPI had
> "geeky" people power available and optimized for that. That seems to
> have served the organization quite well: both the website and membership
> management had been dead for a very long time in the Plone days, with
> nobody willing to touch the thing with a ten foot pole, before the
> technical revamp that happened in recent years after the switch to
> something else.

Agreed.

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.

Hi Bdale,

On 2016-08-18 22:53, Bdale Garbee wrote:
> Filipus Klutiero <chealer(at)gmail(dot)com> writes:
>
>> While having to learn a new syntax is already quite a disadvantage, at
>> least for me
> It is for all of us... which is exactly why we moved to the ikiwiki+git
> combination... because at least at the time it used technology and
> skills that all of the board members were comfortable with, and enabling
> ourselves to be able to more easily contribute to the web content was a
> higher priority than enabling "others" who might not have the same
> skills to do so.

I am not sure of your point, but as I wrote, I had forgotten that SPI previously used Plone. I did not mean to criticize the switch from Plone. I do not remember using Plone except as a visitor. I have no idea if the move was good, bad or irrelevant. The move may have been a good one, but having completed that change does not prevent going further.

>
> [...]
>
> Frankly, though, the fact that anyone can install the ikiwiki processor
> locally and apply it to a checked out copy of the web content git
> repository means that it may just be a better plan to assume that anyone
> who wants to contribute will be willing to "figure things out"...

This may be repeating Joshua's informal message, but this seems to equate the capacity to learn with the desire to learn. I can probably learn Klingon, but I have no desire at all to do so. Even if everyone *could* contribute to the current website does not mean that everyone will be *willing* to learn how it is done (and to invest the time needed to setup the necessary environment).

>
> Bdale

--
Filipus Klutiero
http://www.philippecloutier.com

On Thu, Aug 18, 2016 at 08:55:48PM -0400, Filipus Klutiero wrote:
> On 2016-08-14 16:25, Jonathan McDowell wrote:
> >Based on experience managing a number of wikis I think the workload
> >involved in helping people who want to contribute at present but
> >can't deal with ikiwiki is significantly lower than dealing with an
> >open (or even approval based) wiki or CMS.
>
> I am not sure what you meant exactly by "deal", but recruitment of
> contributors unable to *use* the current system is not the main
> benefit I see. I was rather seeing a switch as a way to make
> contributing more appealing.

Are you saying that you think people don't contribute because of the
overhead of submitting changes to the ikiwiki+git system, rather than
because they don't understand it?

> As for the workload involved in dealing with wikis or CMS-s, were you
> referring to content administration?

I'm referring to the unfortunate way in which spammers attach themselves
to any uncurated website that allows anonymous or easy registration
submissions. I think we'd spend a lot more time cleaning things up if
the system in use allowed such things, and that the website as a whole
would suffer as a result - the negative impact of having to clean such
things up would seriously outweigh the drive-by improvements from people
who don't want to email webmaster@ or submit a Markdown patch.

J.

--
Revd Jonathan McDowell, ULC | Can I drink your juice?

On 2016-08-20 12:20, Jonathan McDowell wrote:
> On Thu, Aug 18, 2016 at 08:55:48PM -0400, Filipus Klutiero wrote:
>> On 2016-08-14 16:25, Jonathan McDowell wrote:
>>> Based on experience managing a number of wikis I think the workload
>>> involved in helping people who want to contribute at present but
>>> can't deal with ikiwiki is significantly lower than dealing with an
>>> open (or even approval based) wiki or CMS.
>> I am not sure what you meant exactly by "deal", but recruitment of
>> contributors unable to *use* the current system is not the main
>> benefit I see. I was rather seeing a switch as a way to make
>> contributing more appealing.
> Are you saying that you think people don't contribute because of the
> overhead of submitting changes to the ikiwiki+git system, rather than
> because they don't understand it?

Not exactly. I am saying that people would contribute more if:

1. The knowledge required to contribute was less costly to learn, or already more widespread
2. There was no need to setup a rare system to validate a suggested solution before submitting it.
3. It could be determined before proposing a change whether the same proposition is already waiting processing.
4. It could be determined before proposing a change whether the same proposition was already made and rejected.
5. Proposing a change was less costly, indeed.
6. It was possible to receive a confirmation that a change was queued when proposing it.

(As I initially conceded, some of these can be achieved without adopting a CMS or wiki)

>
>> As for the workload involved in dealing with wikis or CMS-s, were you
>> referring to content administration?
> I'm referring to the unfortunate way in which spammers attach themselves
> to any uncurated website that allows anonymous or easy registration
> submissions.

OK. As I wrote, this request does not demand to allow anonymous modifications. In fact, I would be concerned with allowing anonymous modifications, except *perhaps* on specific pages. As for easy registration submissions, the registration process could be the same as the process to become a SPI member if we are willing to restrict submissions to SPI members, which I consider most reasonable (it would already be a lot more open). While allowing this might cause more fraudulent registrations as SPI members, it would largely reduce the proportion of legitimate changes going to webmaster(at)spi-inc(dot)org(dot)

> I think we'd spend a lot more time cleaning things up if
> the system in use allowed such things, and that the website as a whole
> would suffer as a result - the negative impact of having to clean such
> things up would seriously outweigh the drive-by improvements from people
> who don't want to email webmaster@ or submit a Markdown patch.

Switching to a CMS or wiki does not necessarily mean we need to spend time removing spam. Modifications from non-members do not need to be allowed, and if they are, they can be set to not display by default ("pending changes").

And the advantages of solving this are not limited to "the drive-by improvements from people who don't want to email webmaster@ or submit a Markdown patch", as you describe them. Solving this optimizes the work of those people who are willing to contribute in the current situation, and there are also indirect benefits. Every time we ease contributing, we increase the number of contributions from newcomers who will build a trust in the project's capacity to treat their contributions properly. And contributing is also how contributors learn more about a project, which is necessary for them to become better contributors.

2 of the 3 social production projects I contributed the most to are extremely open and easy to contribute to. In both cases, I made my first contribution from my browser.

The first one is Tiki, where I started doing issue triaging in an ITS which could be manipulated from browser. When I was recruited as a developer, I said I had no time to contribute more. Yet, a few months later I was learning the implementation languages (PHP, Smarty and SQL, which are also relatively easy) and becoming a top contributor, until I realized I had become addicted to that project and resigned.

The other project is Wikipedia, which I did not want to contribute to for several months, before I was so tempted to intervene that I created an account and made a first comment. And of course, I then learned the syntax, the policies, perfected my English, and made thousands of edits.

In both of these cases, I had no intention to become a regular contributor when I made my first contribution. At that time, I would have bet that I would not contribute thousands of hours to these projects. Perhaps it would have been more efficient for me to learn the skills necessary to contribute to different projects which were less open and easy to contribute to, but that is not what happened, because I was never looking for a project to get involved in, I just noticed issues in these projects and found I could easily help solving them. It is just too easy to get involved when... it is easy to start contributing.

That being said, I have stopped contributing to these 2 projects because their openness is extreme and hurts their products and the productivity of contributors. One could say the same thing which got me involved got me to leave later, but I think we can distinguish because the technical barriers to entry and openness. I am asking here to lower the technical barriers to entry, not to increase openness. I tend to think that more openness would also help, but that is not necessary to solve this issue.

Regarding your "drive-by" qualification, you might be right if you are implying that a potential contributor's knowledge of markup languages is correlated to his level of relevant experience, but I would counter that the level of relevant experience is inversely proportional to the probability of that potential contributor prioritizing work for SPI among all the options he chooses to spend his time on.

--
Filipus Klutiero
http://www.philippecloutier.com

On 08/20/2016 06:02 PM, Filipus Klutiero wrote:

> Not exactly. I am saying that people would contribute more if:
>
> 1. The knowledge required to contribute was less costly to learn, or
> already more widespread
> 2. There was no need to setup a rare system to validate a suggested
> solution before submitting it.
> 3. It could be determined before proposing a change whether the same
> proposition is already waiting processing.
> 4. It could be determined before proposing a change whether the same
> proposition was already made and rejected.
> 5. Proposing a change was less costly, indeed.
> 6. It was possible to receive a confirmation that a change was queued
> when proposing it.

Exactly. The barrier to contribution should be as close to sea level as
possible. I am fully capable of firing up the SPI infrastructure on a
test instance, am I going to? No. I have better things to do.

Now, if you give me the ability to log into the website, write a blog or
an article or update a web page with more relevant info that can be
queued for review and then published? Yes, I would happily do that.

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

Joshua D. Drake writes ("Re: Issue #2 - Allow contributions to website from browser"):
> Exactly. The barrier to contribution should be as close to sea level as
> possible. I am fully capable of firing up the SPI infrastructure on a
> test instance, am I going to? No. I have better things to do.

"Firing up the SPI infrastructure as a test instance". Are we still
talking about ikiwiki ?!

Ian.

--
Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

On 08/23/2016 03:38 AM, Ian Jackson wrote:
> Joshua D. Drake writes ("Re: Issue #2 - Allow contributions to website from browser"):
>> Exactly. The barrier to contribution should be as close to sea level as
>> possible. I am fully capable of firing up the SPI infrastructure on a
>> test instance, am I going to? No. I have better things to do.
>
> "Firing up the SPI infrastructure as a test instance". Are we still
> talking about ikiwiki ?!

I was talking about the website as a whole. I don't know what it takes
to get ikiwiki up and running. I shouldn't need to know. We aren't a
software project.

JD

>
> Ian.
>

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.

On Sat, Aug 20, 2016 at 09:02:22PM -0400, Filipus Klutiero wrote:
> On 2016-08-20 12:20, Jonathan McDowell wrote:
> > Are you saying that you think people don't contribute because of the
> > overhead of submitting changes to the ikiwiki+git system, rather than
> > because they don't understand it?
>
> Not exactly. I am saying that people would contribute more if:
>

Perhaps a bit of history may or may not be useful, as I was the one who
installed plone.

When I initially joined SPI, the entire site was run using a similar
system that Debian uses - wml. This had a number of unique features,
such as the ability to have translations in multiple languages.
Unfortunately, it ended up that I was the only one who was updating the
website. Thus, I decided along similar lines, with a similar lack of
evidence, that a lower barrier to entry would encourage more people to
contribute to the site.

In hindsight, I was wrong. The number of contributors didn't magically
increase because someone could type stuff in to a text box and have that
submitted to review. It didn't increase because there wasn't the number
of people who were willing to create content, and those who were didn't
like dealing with a CMS.

After I left the board, SPI moved to ikiwiki. This has a number of
advantages over both plone and wml, and more importantly, is the choice
of workflow from people who actually contribute. The amount of extra
overhead from running a CMS system (which is considerable) is simply not
worth the potential (and generally non-existent, or at a minimum,
non-persisting) contributions we may get.

I'd urge the board to concentrate on things that matter to member
projects rather than get side-lined into this discussion.

Neil

Hi Neil,

On 2016-08-23 11:00, Neil McGovern wrote:
> On Sat, Aug 20, 2016 at 09:02:22PM -0400, Filipus Klutiero wrote:
>> On 2016-08-20 12:20, Jonathan McDowell wrote:
>>> Are you saying that you think people don't contribute because of the
>>> overhead of submitting changes to the ikiwiki+git system, rather than
>>> because they don't understand it?
>> Not exactly. I am saying that people would contribute more if:
>>
> Perhaps a bit of history may or may not be useful, as I was the one who
> installed plone.
>
> When I initially joined SPI, the entire site was run using a similar
> system that Debian uses - wml.

Thank you, I had forgotten that too. The Wayback machine does show that SPI switched to Plone in August 2006.

> Thus, I decided along similar lines, with a similar lack of
> evidence, that a lower barrier to entry would encourage more people to
> contribute to the site.
>
> In hindsight, I was wrong. The number of contributors didn't magically
> increase because someone could type stuff in to a text box and have that
> submitted to review. It didn't increase because there wasn't the number
> of people who were willing to create content, and those who were didn't
> like dealing with a CMS.

Not sure what you mean. Few contributors like dealing with whatever publishing system is in place. Of course reducing the barriers does not necessarily mean there will be an increase in the number of contributors.

>
> After I left the board, SPI moved to ikiwiki. This has a number of
> advantages over both plone and wml, and more importantly, is the choice
> of workflow from people who actually contribute.

What do you mean by "is the choice of workflow from people who actually contribute"?
> The amount of extra
> overhead from running a CMS system (which is considerable) [...]

What kind of overhead are you referring to?

>
> I'd urge the board to concentrate on things that matter to member
> projects [...]

This is a little vague, but if you have concrete suggestions, thanks for proposing these in a different topic.

--
Filipus Klutiero
http://www.philippecloutier.com