Wikitech-l April 2008

wikitech-l@lists.wikimedia.org

100 participants
97 discussions

Re: [Wikitech-l] Primary account for single user login
by Anon Sricharoenchai 08 Apr '08

08 Apr '08

> > Message: 8 > Date: Fri, 12 Oct 2007 17:59:22 +0200 > From: GerardM <gerard.meijssen(a)gmail.com> > Subject: Re: [Wikitech-l] Primary account for single user login > > Hoi, > This issue has been decided. Seniority is not fair either; there are > hundreds if not thousands of users that have done no or only a few edits and > I would not consider it fair when a person with say over 10.000 edits should > have to defer to these typically inactive users. 1. Yes, it's not fair, but this is the truth on wikimedia project that ones have to admit. Imagine if, all wikimedia sites has a single user login since when it is first established, the one who first register will own that username for all wikimedia sites. 2. The person with less edits, doesn't mean that they are less active than the one with more edits. And according to, http://en.wikipedia.org/wiki/Wikipedia:Edit_count, ``Edit counts do not necessarily reflect the value of a user's contributions to the Wikipedia project.'' What if, some users have less edits count, * since they deliberately edit, preview, edit, and preview the articles, over and over, before submitting the deliberated versions to wikimedia sites. * Some users edit, edit and edit the articles in their offline storage, over and over, before submitting the only final versions to wikimedia sites. While some users have more edits count, * since they often submit so many changes, without previewing it first, and have to correct the undeliberated edit, over and over. * Some users often submit so many minor changes, over and over, rather than accumulate the changes resulting in fewer edits count. * Some users do so many robot routines by themselves, rather than letting the real robot to do those tasks. * Some users often take part in many edit wars. * Some users often take part in many arguments in many talk pages. What if, the users with less edits count, try to increase their edits count to take back the status of primary account. What if, they decide to change their habit of editing, to increase the edits count, * by submitting many edits without deliberated preview, * by splitting the accumulated changes into many minor edits, and submit them separately, * by stopping their robots, and do those robot routines by themselves, * by joining edit wars. 3. According to 2) above, I think, the better measurement of activeness is to measure the time between the first edit and the last edit of that username. The formula will look like this, activeness = last edit time - first edit time > > A choice has been made and as always, there will be people that will find an > un-justice. There were many discussions and a choice was made. It is not > good to revisit things continuously, it is good to finish things so that > there is no point to it any more. > > Thanks, > GerardM > > On 10/12/07, Anon Sricharoenchai <anon.hui(a)gmail.com> wrote: > > > > According to the conflict resolution process, that the account with > > most edits is selected as a primary account for that username, this > > may sound reasonable for the username that is owned by the same person > > on all wikimedia sites. > > > > But the problem will come when the same username on those wikimedia > > sites is owned by different person and they are actively in used. > > The active account that has registered first (seniority rule) should > > rather be considered the primary account. > > Since, I think the person who register first should own that username > > on the unified > > wikimedia sites. > > > > Imagine, what if the wikimedia sites have been unified ever since the > > sites are > > first established long time ago (that their accounts have never been > > separated), > > the person who register first will own that username on all of the > > wikimedia > > sites. > > The person who come after will be unable to use the registered > > username, and have > > to choose their alternate username. > > This logic should also apply on current wikimedia sites, after it have > > been > > unified. > >

8 13

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [32846] trunk/phase3/includes
by Simetrical 07 Apr '08

07 Apr '08

On Sun, Apr 6, 2008 at 6:18 AM, <tstarling(a)svn.wikimedia.org> wrote: > * Use protected instead of private. Private should not be used ever. That's a pretty strong statement. If you use protected, you can't freely change around the methods unless you're sure nobody's actually extended the class (in which case, what harm would there have been in using private to start with?). If you use private, you can always change it to protected later if it's useful, but not vice versa.

3 5

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [32901] trunk/extensions/GlobalBlocking/GlobalBlocking.i18n.php
by Simetrical 07 Apr '08

07 Apr '08

On Mon, Apr 7, 2008 at 5:00 AM, <werdna(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > I'm told that aliasing messages doesn't play nicely with BetaWiki. Changing these aliases to copies of the associated message. > - 'globalblocking-search-ip' => wfMsg( 'ipaddress' ), > + 'globalblocking-search-ip' => 'IP Address:', That would also presumably force 'ipaddress' to get looked up in the message cache, database, God knows where as soon as this file is loaded, even if this particular message would never have to otherwise be looked up.

1 0

Random "how the world feels" from London PM
by David Gerard 07 Apr '08

07 Apr '08

On Thursday night, I went to London PerlMongers social drinks and guzzled ridiculous quantites of Adnam's Oyster Stout and talked rubbish with geeks. Minor anecdotal notes on our public relations with the advanced geek crowd: * They really wish MediaWiki had decent WYSIWYG editing - Wikipedia's wikitext is so full of template code it repels casual editors. I explained the technical problems ("it's not a parser, it's a twisty maze of regexps" - they recoiled in horror) and that we're working on it. (Current status: promising vaporware.) They want WYSIWYG editing because they want to be able to say "no" to installing Confluence, which is horrible to administer and not much better to use. * I told the story of why MediaWiki is written in PHP. (Magnus had read up on PHP to make some changes to NuPedia code, and decided he needed a project. So Phase 2 is Magnus' first ever proper PHP program ...) * They really want machine-readability from Wikipedia. The infobox templates on Wikipedia are getting there. Mostly what they need is standardisation (is the image called "image", "Image" or "Img"?), and a base template that's {{Persondata}} or a reasonable approximation. This is a matter of parser-functions in the template wikitext on the 'pedia, but it's something someone needs to take on as a project: to re-plumb the templates without breaking the nice exposed external interface. Who knows parser-function code and is feeling ambitious and patient? - d.

5 7

Re: [Wikitech-l] GSoC Project: Category Moving
by Samuel Wantman 06 Apr '08

06 Apr '08

I don't know if this has been discussed, but I'm hoping some serious consideration could be put into creating a category history that can be viewed and used for reverting. Every addition and removal of an article should be kept in the history. It should be possible to revert every change. Categories should be able to be put on watchlists. Without the ability to watch a category, see its history and revert changes, it is really not possible to get the categorization of articles to improve much. Considering the lack of these "wiki" features it is quite remarkable that categories have gotten as good as they are in several projects. It is extremely frustrating to create and populate a category with hundreds of members, just to have someone undo all or most of the effort. There is no easy way to monitor a category or undo the damage. This technical limitation has the effect of strengthening the status quo and quashing innovation. -- Samuel Wantman [[en:User:Sam]]

6 12

#4150 - Show New pages in Special:Contribution
by Nicolas Dumazet 06 Apr '08

06 Apr '08

Related to https://bugzilla.wikimedia.org/show_bug.cgi?id=4150 I took a look at this bug today, and it seems that only the recentpages table stores the newness of a page. To show this information, a scheme change is apparently needed. * I first thought at a rev_type field, similar to rc_type. This field would identify revisions creating a new page, but could also be used to flag special operations, such as page moves, or page protections that are currently null revisions. * Bryan then suggested that a page_first, a foreign key to the first revision of the page, similarly to page_latest, could solve bug #4150. On a sidenote, I also found #11181, "Mark bot edits in history", which might be related : if these features were to be implemented in the same time, a bitfield rev_flags could be worth looking at. -- Nicolas Dumazet — NicDumZ Deuxième année ENSIMAG.

2 1

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [32816] trunk/extensions/Renameuser/SpecialRenameuser_body.php
by Simetrical 05 Apr '08

05 Apr '08

On Sat, Apr 5, 2008 at 12:44 PM, <aaron(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > Rename block/rights log (bug 7011) > + $dbw->update( 'logging', > + array( 'log_title' => $newTitle->getDBKey() ), > + array( 'log_type' => array( 'block', 'rights' ), > + 'log_namespace' => NS_USER, > + 'log_title' => $oldTitle->getDBKey() ), > + __METHOD__, > + array( 'USE INDEX' => 'page_time' ) ); Why don't you just drop the log_type condition and rename all old logs?

2 2

Editing/Adding buttons in the edit window
by Jonathan Nowacki 04 Apr '08

04 Apr '08

I would like to create an extension that will allow you to add a buttons to the edit window. Right now there are: - Bold - Italics - Underline - Hyperlink - Headline - Image and other buttons. Any advice on how to go about adding more features to the edit toolbar?

2 1

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [32765] trunk/phase3/includes/ChangesList.php
by Niklas Laxström 04 Apr '08

04 Apr '08

On 04/04/2008, aaron(a)svn.wikimedia.org <aaron(a)svn.wikimedia.org> wrote: Modified: trunk/phase3/includes/ChangesList.php > - function arrow( $dir, $alt='' ) { > + private function arrow( $dir, $alt='' ) { > - function sideArrow() { > + private function sideArrow() { > - function downArrow() { > + private function downArrow() { > - function spacerArrow() { > + private function spacerArrow() { Private? So much for backwards compatibility. Anyway now would be a good time to think what to do to them. 1) Make them public or protected as they were? 2) Move them to a better place (GlobalFunctions? Xml?) 3) Should they be copied to extensions using them? -- Niklas Laxström

2 1

GSoC : Getting feedback on several ideas
by Nicolas Dumazet 03 Apr '08

03 Apr '08

Hi ! ;) As some of you may already know from IRC / Timjoh's recent thread, both TimJoh and I planned to work toward category moving for GSoC this year. TimJoh is already working in collaboration with Catrope, and has indeed a better overview on the subject than I have : I am going to use the GSoC deadline extension (up to monday) to withdraw my current application, and to work on another wikimedia feature. :) I have been around for some weeks now, and I've heard of several recurrent topics : Ability to watch the changes on the members of a category, better logging (although I believe that Aaron is currently taking care of this), Global [ preferences / (IP) blocking / logging / insert_any_local_feature_here ] ... Some features here won't get implemented before *some other major current issue*, but the coding part of GSoC is in two months, and by this time, with your help, one or more of these features might get easier to implement. I really think that with two months of full time coding, with your collaboration, I could be able to write a significant part of one of these features. But my question today is : would someone support me in one of these tasks ? Understand me, I've read, for example, a long ML post from Simetrical, and the bug issue, both on Global IP blocking : These clearly give implementation ideas, weights a choice against another... Yet no one seemed to answer *oh, sounds interesting, I will look upon this [later]* ! If I were to try to work on it, for example, would someone get really interested and answer my questions :) ? I am really motivated to work on MediaWiki this summer. Yet, I don't want to try to implement a feature that draws little interest or is highly controversial : I really don't want to sound bothering when I'll be asking for a little hand "oh, not again #him# with that **** feature" :þ Please, show me the way :) Cheers, -- Nicolas Dumazet — NicDumZ Deuxième année ENSIMAG.

3 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l April 2008