As to restricting new accounts: This is what we have already done, but it still is not enough, as there are only 1-2 people with the authority and common sense to dictate what is and is not appropriate and fitting material for the wiki. In addition, the wide collaborative structure is seen as very much a benefit, owing to the large group of people (faculty, staff, students, alumni) who would have an interest in contributing. Thus, we wish to allow anonymous editing etc. In short, too many people need access to easy editing to restrict our user group so much.
As to a "stable" time: Yes, we really want to not limit access as much as possible, to encourage widespread contribution. On the "stable" time, this is actually where I am currently headed with my modifications based on the patrolled flag, and it is only present in the recent changes table, and that table is cleared after a certain amount of time, of a certain number of edits, I believe. This would cause whatever was in cur to be displayed.
This is part of the reason I'm swaying away from the current course I've taken, and towards a cleaner approach, but I will bring up the "stable time" to see if it's an acceptable solution. Also, part of the problem with this is how does it reach a stable point, as *all* evidence of an edit by a user should not be evident from the wiki, except to sysops or the like. (editing should display the previously approved entry, and only approved entries should appear in the history etc.) Because of all of this, I'm thinking of trying to implement a kind of queue of edits, which would bee looked at, and then approved or rejected, and if rejected, just dropped, if approved, added as if the user which submitted them had added them themselves.
-Randy
On Fri, 1 Oct 2004 01:26:35 -0700 (PDT), leercontainer-wikimedia@yahoo.com leercontainer-wikimedia@yahoo.com wrote:
As far as I understood this message, you are not looking for a way of limiting access and edits, merely a way of approving edits.
I have seen a feature that I think would be usable for you on a MediaWiki roadmap some time ago. It was supposed to be an alternative to protecting pages that is already implemented in some other wiki software.
What the feature did was that you could specify a time period that a page had to be "stable" before edits to a page were "activated", and thereby presented to the readers. Lets say this period was set to 7 days "the approvers" would have 7 days to discover and fix any maliscious edits before they were presented to the readers of the website.
I don't know what wiki software has this feature, or if it still is on some roadmap, but I myself find it a very neat feature, and with the new database scheme it should't be too hard to implement in MediaWiki either I'm guessing.
--Dittaeva
--- Randy Becker lemnar@gmail.com wrote:
I'm a high school student involved in our website (http://www.rileyhighschool.com/). After taking a look at the sorry state of our site, and subsequently visiting wikipedia, I came to the realization that a wiki, especially mediawiki, would be enormously beneficial to our site in many ways. I investigated further, installed 1.3, got some content in, customized monobook a little bit, got familiar with the software. I decided that it really would be a great improvement, and continued further testing. Upon further review, and in conversation with the administration, it was determined that the principal objection to using mediawiki as our primary site was that anyone could edit. Although it has been presented that this is not a serious problem in practice, it was still too much of a risk for them to take. Downtrodden, but not discouraged, knowing that mediawiki is an open source product, and being familiar with php and mysql, I looked further into what was available. Ultimately, it was determined that unapproved edits cannot come to exist in the first place, irregardless of the ease of their removal. I began looking for a way to implement an approval mechanism.
On #mediawiki it was suggested that I look into the recent changes patrolling in 1.4 as a potential method of implementing this solution. I have done this and determined that it will be just as difficult to use this as it will be to implement a cleaner solution, involving a new table in the database and an approval mechanism. Therefore, I'm here to ask for suggestions, comments, and help implementing this, or a similarly acceptable solution.
-Randy