On Wed, Aug 3, 2011 at 10:32 PM, Jean Hollis Weber <[email protected]> wrote: > I've got completely lost in all the mutations of the "Refactoring" > thread, and don't recall all that has been said, so please forgive me if > what I'm about to suggest has been dealt with already. >
Thanks for starting a new thread. > Two low-barrier methods I have seen work quite successfully on wikis, > forums, and similar sites are: > > 1) People must ask for an account; they can't self-subscribe. Nothing is > required except a few words about who you are and why you want an > account. Any one of several people authorised to approve or reject these > requests can deal with them expeditiously. Very few spammers, in my > experience, take the trouble to actually request accounts. > I think it depends more on permissions than accounts. So if the basic user account allows you to write to a comment page, or "watch" a page to be notified of changes, etc., I think these are actions we can safely permit to anyone. These are analogous to what a user can do on any Apache list. They can join the list, post to the list, ask questions, submit (via the list) corrections to the website and patches to the code, for review. What they cannot do is change the website and code directly. Those rights are reserved to committers, those who are trusted to do those tasks and elected by the PPMC. So the wiki is a different tool. It makes some things easier. The "affordances" of a wiki (as the design people would say) is the easy ability to do collaborative editing of hypertext. But the qualities of the tool should not (IMHO) change our fundamental orientation to the different roles of contributors and committers. Of course, these roles will map differently to different tools, based on the capabilities of those tools. But the roles are part of how Apache works. So I think you are asking the right questions. One useful way of thinking of it (to me at least) is asking how the capabilities of the tool map to Apache Project roles: 1) User 2) Developer (also called Contributor) 2) Committer 3) PMC member See: http://www.apache.org/foundation/how-it-works.html#roles > 2) Alternatively, or in addition, the first X edits/ contributions/ > whatever are moderated by a group of people, any one of whom can approve > or reject the items. After X acceptable contributions, the person is > then allowed to edit the wiki without further supervision -- until or > unless they start posting inappropriate material such as spam. Again, > very few spammers will take the trouble to post some useful info before > going into spam mode. > > These methods deal with the vast majority, if not all, of the concerns I > have seen Rob expressing about systems with no control at all, but at > the same time they do not require more time or commitment on the > contributors' part to be authorised to participate. > The other set of concerns I had was with respect to content license. Today we seem to have a mix of 4 different licenses for contributed content, as well as content that does not have any evident license attached to it. I realize cleaning up the past is nearly impossible, But is there anything we can do better going forward? In particular, please note that I'd like to encourage IBM contributions of documentation to the project, along with our Symphony work. For example, we have doc related to enterprise deployment and this is applicable to OpenOffice as well as Symphony. But if we contribute this under Apache 2.0 and then it is edited by anonymous (or pseudonymous) users who have not signed the iCLA, then our contributions can be immediately contaminated by unlicensed (or incompatibly licensed) changes, making it impossible for us to use future revisions of own doc. As you can imagine, that would make it very difficult for us, or any other corporation, to collaborate on documentation. So that's the essential trade-off. If we require iCLA for substantial content contributors, then you will cause some contributors to stop participating But if you don't require an iCLA, then you will inhibit participation from corporations. And note that this is true for all reusable content in the project. So code, help, documentation and translations. If we want participation from corporations then we need to have the means to establish and maintain the pedigree of the contributions under a consistent license (or set of compatible licenses). > AFAIK, most wikis & similar sites provide some way to limit the editing > of specific pages to a smaller group of people (admins or whatever). > > --Jean > > > >
