开云体育

In the beta group Frances wrote:

I also like the idea of having a list of samples available for
list-owners to tweak / adopt if they wish. ("the curated list").

Rather than ask Mark to open up Beta's wiki, which he may have reasons not to do, I realized I've got a couple other options. One of them is to clone my YahooGroupedia wiki for use with Groups.io. So that I've done:


The other is to start using GMF's wiki, which I've also done:
/org/groupsio/GroupManagersForum/wiki

I'm more familiar with editing PBworks, and I think it is more feature-rich (e.g. an automatically generated Table of Contents for a lengthy page), so that was my first inclination. But there's no denying the simplicity of having the Wiki access control be implicit in group membership.

One difference is that PBworks' wiki is visible to the public, where GMF's is not, and cannot be made so (there's no selection for "Public"). This has its plusses and minuses. For example, a tutorial on how to sign in to a Groups.io group would only be useful in a public wiki. There may be subjects that shouldn't be in a public wiki, but given that GMF has open membership, they probably shouldn't be here either. So at the moment the only advantage to GMF's wiki seems to be the convenience for GMF members (they don't have to obtain a PBworks account to edit the wiki, nor keep a bookmark or something to remember where it is).

Probably the most significant advantage of using GMF's wiki is "dogfooding" - that is, the more we use the native resource the better we'll understand it and how to use it in our own groups, and the better we will be able to report bugs and suggest improvements.

So my inclination is to eventually remove the Best Practices topic from Groupsiopedia, and reserve that wiki for topics that are more useful if they're in a public wiki. I'll try and remember to provide cross-links between the two when I do that.

Opinions?

-- Shal