That's not a problem at all. That would be one of the reasons I'm personally a fan of open source: that if *I* want a feature, then I can add it myself, even if I'm the only person in the world who wants it.
I'm mainly just looking for ideas or suggestions on implementation, and to let it be known that I'm going to be attempting this, and if anyone wants to help, all the better, or if not that's perfectly fine too. I just figured that in the interest of not wasting effort on the possibility of someone else being interested, or to get an idea of how best to go about this, and for more experienced people to give some advice as to potential pitfalls etc. it would be a good idea to post this here.
All this being said, I do think that a wiki, and particularly MediaWiki, (Which I've come to *really* like in many many ways) is the best tool for the job, and unfortunately the political situation I'm in won't allow for MediaWiki as it exists today, even though I think it would be the best solution, it is just a bit too radical for our organization. I would *love* to implement it as a standard install, but it just isn't going to happen that way, and rather than not happen at all, I'd like to at least make use of some of the advantages a similar environment could provide.
-Randy
On Sat, 2 Oct 2004 00:33:31 +0200, Jens Ropers ropers@ropersonline.com wrote:
What I'm going to say is purely my personal opinion and I've never contributed a single line of code to MediaWiki:
Given your below email, I wonder if you might not be better off looking at other solutions instead of MediaWiki. Yes, MediaWiki is very powerful and we like it A LOT. But it is mostly built for a defined job, and it just isn't a Content Management System (CMS) -- see:
http://meta.wikimedia.org/wiki/Wiki_Uses#What_is_MediaWiki_-_not.3F
Yes, all the features you are looking for may (or may not) be forthcoming sooner or later, but if I were you I wouldn't hold my breath. Again, MediaWiki is built mostly with Wikipedia-alike wikis in mind, and I dare say primarily built for Wikipedia. If others can use MediaWiki, hey, that's great! If others have good ideas that they can code and contribute to MediaWiki, that's even better! But if you were to ask our developers to code some feature that we don't have and don't need yet (because there isn't consensus yet on what Wikipedia's approval mechanism needs are), if you were to ask people to code a feature just because you could use it for your installation, then you'd probably find yourself sorely disappointed by the response. (And I'm not saying that you'd actually asked thus yet -- you haven't.)
Again, if you can code and contribute a feature or even you're more than welcome. Feature suggestions are welcome too, but-- I guess what I'm saying is that there are no guarantees in that area.
There are a lot of Open Source CMSs out there -- a cursory glance returned these: http://www.mamboserver.com/ http://typo3.com/ http://plone.org/ There also are truckloads of other Wiki software projects, some of which may include the features you are looking for. Google for them.
Then again, I am not speaking for others on this list and I may be wrong.
-- ropers [[en:User:Ropers]] www.ropersonline.com
On 1 Oct 2004, at 13:36, Randy Becker wrote:
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
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l