Wikipedia-l June 2002

wikipedia-l@lists.wikimedia.org

37 participants
155 discussions

Re: [Wikipedia-l] New codebase status- Now, Editors?
by rose.parks＠att.net 02 Jun '02

02 Jun '02

Members- I couldn't agree more. The title "editor" implies a totally different job function to me. Yes, editors deal with content, but they usually review, alter, and/or approve content. As was already said, in this sense, all Wikipedians are editors. Another issue is whether we want to identify members' functions, at all, on the user page. There are many other ways to identify developers and sysops on Wikipedia and they should be considered too. There could be a sysops page and a developers page with a list of such people. Frankly, I like the site as it is. Developes are identified by going to Source Forge, usually, and if a developer has not been included on this site, I think they can simply ask. Sysops know who they are by the sidebar on their view of the Wikipedia pages. Maybe someone in favor of ths system can explain the advantages to me. As Ever, Ruth Ifcher -- > On 6/1/02 6:52 PM, "lcrocker(a)nupedia.com" <lcrocker(a)nupedia.com> wrote: > > > > > We need some status for a generally well-known member of the > > group who we trust to make content choices like editing > > protected pages, temporarily banning vandals, deleting pages, > > and so on. We also need a status for more dangerous things like > > database queries and other maintenance tasks. The current > > software calls these "sysop" and "developer", but I think "editor" and > > "sysop" makes more sense. Developers will probably have logins to the > > server and direct database access, so they don't need any rights the > > software knows about--they exist outside the software. > > > "Editor" is a bad name, because everyone is an editor, and should be > considered as such. I've already expressed my views on the need for sysops > etc. > > [Wikipedia-l] > To manage your subscription to this list, please go here: > http://www.nupedia.com/mailman/listinfo/wikipedia-l

1 0

Re: [Wikipedia-l] New codebase status- Now, Editors?
by lcrocker＠nupedia.com 02 Jun '02

02 Jun '02

> I have tried to read the endless posts to the Wiki >lists, but perhaps I missed something. On Mr. Crocker's >test site, did we decide to show on the Users page, that >certain members are "editors," and "sysops?" And, if so, >what is a "editor?" That's just my impression of the better names for what we now call "sysop" and "developer"--and those can be changed to whatever we decide on when we have an actual policy on the matter. We need some status for a generally well-known member of the group who we trust to make content choices like editing protected pages, temporarily banning vandals, deleting pages, and so on. We also need a status for more dangerous things like database queries and other maintenance tasks. The current software calls these "sysop" and "developer", but I think "editor" and "sysop" makes more sense. Developers will probably have logins to the server and direct database access, so they don't need any rights the software knows about--they exist outside the software. 0

2 1

Re: [Wikipedia-l] New codebase status- Now, Editors?
by rose.parks＠att.net 01 Jun '02

01 Jun '02

Members, I have tried to read the endless posts to the Wiki lists, but perhaps I missed something. On Mr. Crocker's test site, did we decide to show on the Users page, that certain members are "editors," and "sysops?" And, if so, what is a "editor?" I think all members should be aware of this. I have seen no consensus on making anyone an editor. Please explain. Please explain, also, what makes a member an editor? As Ever, Ruth Ifcher -- > I think Recent Changes and page history are in something like a final, > usable, and efficient form. Recent changes shows /all/ changes, > without collapsing changes to the same page into one line. Each has a > link to a diff page and the history page. > > Each entry on the history page now has a link to a diff with the > current version, and diff with the immediately previous version. The > date and time, rather than the page name, is the link to the revision > (it seemed silly to have a pageful of links with the same name). > > The diffs are in side-by-side format with context. > > Since the last update, I've also finished a few miscellaneous things > like Random page, user list, and printable versions (this now works > for all pages, even special pages and forms). > > The running version is still at > (http://www.piclab.com/newwiki/wiki.phtml) > > I've set up the Sourceforge bug database at > (http://sourceforge.net/tracker/?group_id=34373&atid=411192) > to which the public can add bugs. > > The feature request tracker is at > (http://sourceforge.net/tracker/index.php?group_id=34373&atid=411195) > > REQUEST: A useful thing for some non-techie to do would be to go > through the old wiki pages of bug reports on the old software, try > the new software, and add bugs to the tracker. Now is also a good > time to go ahead and add missing features to the feature request > tracker so they don't get lost. > > Special thanks to Axel and KQ for their diligent QA work. 0

1 0

Recent Changes layout
by lcrocker＠nupedia.com 01 Jun '02

01 Jun '02

Axel makes a good argument that the new code's simplified layout of the Recent Changes page (see http://www.piclab.com/newwiki/wiki.phtmltitle=Special:Recentchanges ) really is an important loss of functionality. Since his comment, I added an article history link, but I think his comment still applies in general. I think it is of critical importance that this feature be optimized both for function and for speed. I don't want to put the old code back because it's a dog, but if I can find a way to implement the needed features in a faster way, I'm all for it. First, I'd like to solicit an opinion from Jan or other database gurus about what might make the speed better. Currently, it is driven by a single SELECT from the current article table, which is sorted by reverse timestamp (on which there's an index), and with a LIMIT. The old (N changes) feature also required accessing the old versions table and an expensive GROUP BY, which I'd like to avoid if possible. One way I might do that is to create a new "changelog" table, updated on each page change. This would hold the information needed for the RC page which would avoid having to hit the article table or the old versions table at all. It would use basically the same query (by reverse timestamp). It might even be able to do the GROUP BY faster, but if not, it would still have the advantage that multiple changes to the same page would all show up in the list at their appropriate position, which might actually be better, because that would also show the person changing it and other stats which are now buried in the (N changes). Jan, would the increase non-atomicity of the article save process be a problem? MySQL doesn't have transactions, so it's possible that either an aritlce might be saved while recording that fact in the changelog fails, or vice versa. I can't think of any real negative consequences of that (each article's history list would still be accurate, because those go straight to the article tables). Any other ideas? 0

3 2

New codebase status
by lcrocker＠nupedia.com 01 Jun '02

01 Jun '02

I think Recent Changes and page history are in something like a final, usable, and efficient form. Recent changes shows /all/ changes, without collapsing changes to the same page into one line. Each has a link to a diff page and the history page. Each entry on the history page now has a link to a diff with the current version, and diff with the immediately previous version. The date and time, rather than the page name, is the link to the revision (it seemed silly to have a pageful of links with the same name). The diffs are in side-by-side format with context. Since the last update, I've also finished a few miscellaneous things like Random page, user list, and printable versions (this now works for all pages, even special pages and forms). The running version is still at (http://www.piclab.com/newwiki/wiki.phtml) I've set up the Sourceforge bug database at (http://sourceforge.net/tracker/?group_id=34373&atid=411192) to which the public can add bugs. The feature request tracker is at (http://sourceforge.net/tracker/index.php?group_id=34373&atid=411195) REQUEST: A useful thing for some non-techie to do would be to go through the old wiki pages of bug reports on the old software, try the new software, and add bugs to the tracker. Now is also a good time to go ahead and add missing features to the feature request tracker so they don't get lost. Special thanks to Axel and KQ for their diligent QA work. 0

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Wikipedia-l June 2002