>
> 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.
> >
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.
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.
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.
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]]
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.
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?
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
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.