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
Though i am not very familiar with MediaWiki itself you should be able to do this with htaccess rules in apache, just require a password which you give out to trusted users, such as those in the student body to everything that matches /w/wiki.phtml?title=*&action=history
On Thu, 30 Sep 2004 21:02:56 -0500, 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
1. This should solve your problem: http://meta.wikimedia.org/wiki/Preventing_Access Simply prevent anonymous editing and prevent new registrations (otherwise any Internet surfer could just register themselves). Then appoint a person (or a number of persons) who will be responsible for manually creating accounts for anybody who you want to be able to edit. All of these measures are described on the meta page as per the above link.
2. Your needs (which are easily solved by implementing the instructions as per the above link) probably differ significantly from the Wikipedia community's needs for an approval mechanism. One reason why they differ is that there isn't consensus yet within the Wikipedia community on just what kind of an approval mechanism (if any) we want. Incidentally, I am going to present a detailed proposal on this here: http://meta.wikimedia.org/wiki/ Wikimedia_meetup_2005#Possible_speakers_and_workshops Consensus on and implementation of a Wikipedia approval mechanism may be some time off (and, again, may differ significantly from your needs).
-- ropers [[en:User:Ropers]] www.ropersonline.com
On 1 Oct 2004, at 04:02, Randy Becker 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
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
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
On Fri, 1 Oct 2004 06:36:38 -0500, Randy Becker lemnar@gmail.com wrote:
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.
The only drawback to this kind of "invisible queue" is that you might get the same edit submitted multiple times, because it hadn't been approved yet. Also (and potentially even more annoying) you might get edits that cause edit conflicts even though they happened hours apart, e.g.: Current text: "This s a senntence" Alice edits this to: "This is a senntence" Later, Bob edits it to: "This s a sentence" Carol the admin pops these from the approval queue, and the software goes "whoops". No different from a current edit conflict, but potentially a lot more common.
The only way I see round this is to only make the queued edits *partially* invisible: a user asking to edit the page sees a message saying "the following edits have already been submitted for approval" with either a whole load of diffs, or a set of links to diffs (labelled with the edit summary, perhaps). Then they can choose to build on one of those to create their own version.
This is one of the drawbacks I considered: the increased amount of conflicting edits. However, the 'partially' invisible edits would not really meet our needs as it would allow any given user to view unapproved content submitted by any other given user. The administration seems to be rather insistent that this should not happen in any way. It will increase the burden on the approvers, to resolve edit conflicts, but I think that is probably a price they will have to pay for retaining such strong control over the wiki. I wouldn't think that it would be that hard to merge then via the already existing code for merging edits.
-Randy
On Fri, 1 Oct 2004 18:57:54 +0100, Rowan Collins rowan.collins@gmail.com wrote:
On Fri, 1 Oct 2004 06:36:38 -0500, Randy Becker lemnar@gmail.com wrote:
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.
The only drawback to this kind of "invisible queue" is that you might get the same edit submitted multiple times, because it hadn't been approved yet. Also (and potentially even more annoying) you might get edits that cause edit conflicts even though they happened hours apart, e.g.: Current text: "This s a senntence" Alice edits this to: "This is a senntence" Later, Bob edits it to: "This s a sentence" Carol the admin pops these from the approval queue, and the software goes "whoops". No different from a current edit conflict, but potentially a lot more common.
The only way I see round this is to only make the queued edits *partially* invisible: a user asking to edit the page sees a message saying "the following edits have already been submitted for approval" with either a whole load of diffs, or a set of links to diffs (labelled with the edit summary, perhaps). Then they can choose to build on one of those to create their own version.
-- Rowan Collins BSc [IMSoP]
On Fri, 1 Oct 2004 17:25:09 -0500, Randy Becker lemnar@gmail.com wrote:
This is one of the drawbacks I considered: the increased amount of conflicting edits. However, the 'partially' invisible edits would not really meet our needs as it would allow any given user to view unapproved content submitted by any other given user. The administration seems to be rather insistent that this should not happen in any way. It will increase the burden on the approvers, to resolve edit conflicts, but I think that is probably a price they will have to pay for retaining such strong control over the wiki. I wouldn't think that it would be that hard to merge then via the already existing code for merging edits.
Fair enough. And you're quite right, there would only be the conflicts that are too close together in the text for the diff3 feature to merge them. Perhaps you could code an extra check that threw out multiple people suggesting exactly the same change - you only can't do that normally, because the editor has to get a result one way or the other when they hit submit. With an approval queue, it could simply be like the edit was never made.
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
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
On Friday 01 October 2004 13:36, Randy Becker wrote:
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
I think that stable time is not possible solution. Most articles rarely remain stable for any longer amount of time. Someone will fix grammar, remove a comma... there will always be minor or major changes, especially as the changes don't propagate to the article, and the time will always be resetted.
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.
This is possible approach, but who is going to do the approving and rejecting?
see below
On 2 Oct 2004, at 09:10, Nikola Smolenski wrote:
On Friday 01 October 2004 13:36, Randy Becker wrote:
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
I think that stable time is not possible solution. Most articles rarely remain stable for any longer amount of time. Someone will fix grammar, remove a comma... there will always be minor or major changes, especially as the changes don't propagate to the article, and the time will always be resetted.
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.
This is possible approach, but who is going to do the approving and rejecting?
Your questions shall be answered: http://meta.wikimedia.org/wiki/ Wikimedia_meetup_2005#Possible_speakers_and_workshops
;-)
-- ropers [[en:User:Ropers]] www.ropersonline.com
On Sun, 3 Oct 2004 19:28:51 +0200, Jens Ropers ropers@ropersonline.com wrote:
see below
...and then proceeded to quote the whole previous e-mail.
You are allowed to *delete* the quoted text, you know? Or the bulk of it, such as up until the word "Because", so that you still get the context of your reply...
On Thu, Sep 30, 2004 at 09:02:56PM -0500, Randy Becker wrote:
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.
You could alternatively establish a new, hidden, namespace Edit: and if someone clicks the edit-button on a normal page, he will get a diff from the latest Edit: version to the normal version and of course and edit-window of the article in the Edit: namespace. That way you will have only one version in the approval queue, also with a complete version history.
The admin-part (normal sysops!) is simply to move (more replace) the article from Edit: to normal namespace. You also have to move (i.e. change the namespace-key in old) the version history from Edit to normal.
ciao, tom
wikitech-l@lists.wikimedia.org