Tom Purl >> I do think that we can do the addition of new people who want >> to be able to edit the wiki manually. That should also filter >> out the spammers. There is only a delay between wanting to >> edit the wiki and being able to do it the first time. Not >> perfect, but it's something that we can setup right now and try >> out. > > Ok, so here's the proposed workflow: > > 1. Potential tip editer/adder (Veronica Vimlover) visits the > Google vimtips project. On the front page, she sees a message > that tells her to post a message to 'vimtips-general' Google > group if she wants to post or edit a tip. > * Please note that if Veronica visits the wiki page first > instead of the "Project Home" page, she won't know how to > gain the proper access to edit wiki pages since for the > following reasons: > 1. The wiki page itself doesn't tell you how to gain the > necessary access to edit pages. > 2. I don's see how you can define a default "FrontPage" > for the wiki, so we can't specify how to gain edit > access on any sort of wiki front page. > 2. Veronica joins the vimtips Google group and posts a message > asking someone to please give her the necessary access to > edit the wiki page. > * Please note that if she doesn't have a Google id at this > point, she'll need to acquire one. > 3. The admins will monitor the Google group. When Veronica > requests access, one of us will "take ownership" of the > request by responding to the Google group message. > 4. When the project admin has the time, he/she will add give > Veronica a "Project Member" user status, and notify her via > the group that she has the proper access. > * Please note that if Veronica only obtained a Google id so > that she could post to the wiki (like I did), she probably > won't check either the vimtips group or her Gmail very > often. It is therefore possible that Veronica will not > know in a timely fashion that she has be given the proper > access to update the wiki. > * One probable solution to this problem is that we could have > Veronica post her wiki access request the vim mailing list. > This certainly has its advantages, but it might clutter the > vim mailing list, and it would make it more difficult for > the admins to spot access requests. > * Another option would be to have Veronica directly e-mail > one of the project admins listed on the "Project Home" > page, but I think that the disadvantages of this solution > are pretty obvious (problems with admins checking Gmail, > vacations, etc). > > Ok, I know that was long, but I just wanted everyone to know > what was necessary to implement the process of manually adding > wiki editors to the vimtips project. This is definitely more > labor- intensive and error-proned than any web app registration > process that I've ever seen. I still think that the process > listed sets the registration bar too high, and it is not > conducive to a vibrant, robust wiki. > > Also, I know that spam is an issue, but there are tradeoffs. The > process listed above may eliminate 98% of all spam, but what > percentage of possible wiki editors will it also deter? Also, we > need to compare the amount of work we would put into deleting > spam from a different member-only wiki each week with the amount > of time it takes to add dozens of wiki users to the Google wiki > using the process above. > > What do you guys think? Should we still move ahead with the > Google wiki? > > Thanks! > > Tom Purl
I don't see how this process can prevent the Bad Boss from manually acquiring permission and then letting loose his robots to add spam-tips. And he can do this once a week. What is wrong with just having a "visual image based manual check" as the last step of editing a wiki page? (I hope you know what I mean by "visual image based manual check" -- it is the scheme in which the user is shown an slightly distorted image of an alpha numeric string and is required to enter that string in a text input box. A robot cannot read the image and so is unable to do the entry, but a human can do read the image and do the entry so manually.) --Suresh
