The selection phase of the Wikibooks and Wikijunior logo selection
process is coming to a close on Friday. All Wikimedians are encouraged
to come participate and give their opinions on the various logo
candidates.
Come friday, the 10 logo families for each discussion that have
received the most support will move to the next round.
The next round is a discussion round where 1 "best" logo will be
selected from each logo family, with new logos being created or old
logos being modified as necessary. These "best" logos from each family
will compete in the final voting round, from which a single winner
will be selected.
Again, I encourage all Wikimedians to come take a quick look at the
candidates, and express your support for the logo families that you
like the best.
http://meta.wikimedia.org/wiki/Wikibooks/Logohttp://meta.wikimedia.org/wiki/Wikijunior/Logo
--Andrew Whitworth
Is there any committee to make the decision on this?
This decision impact many user's right.
It should be done carefully and peacefully.
Public hearing is a necessary condition.
We should not proceed current implementation of SUL, without public hearing.
On 4/14/08, Anon Sricharoenchai <anon.hui(a)gmail.com> wrote:
> On 4/10/08, Brion Vibber <brion(a)wikimedia.org> wrote:
> > >
> > > Is it possible to defer the creation of global account for the
> > > conflicting username?
> >
> >
> > Currently, it is deferred until one or the other chooses to migrate
> > their account.
> >
> > Note that creation of the global account does not impede the use of
> > conflicting, unmigrated local accounts.
> >
>
>
> The global account will suppress the creation of new local account in
> other wikis.
> Can local account of the conflicting username still be created in
> other wiki (the wiki in which that username hasn't been registered
> before), if all party of a conflicting username, does not yet choose
> to migrate their accounts?
>
> Apart from that, is there currently a plan to later force renaming of
> the conflicting/unmigrated local active account?
> Before doing this decision, we should listen to the opinion from the public.
>
>
> > > 1. To defer until they can negotiate each other, to choose who will
> > > hold the global account.
> > > 2. No automatic process in choosing global account holder.
> > > 3. User must wait until all of the conflicting accounts has been
> > > renamed (by the consent of those account holders, or forced by sysop
> > > if those accounts are impostors), before they can merge and create the
> > > global account.
> >
> > This would mean that stale accounts (for which no negotiation is
> > possible, as there's no one at the other end) would jam up the system
> > entirely, which is unacceptable.
>
>
> As I have already stated before, after some period of time, the
> stale/not-responding accounts can be forced to be renamed.
>
>
> >
> > To make it possible for the system to actually work, we use an automated
> > selection for the global account, which can be overridden manually if
> > and when specific people require it.
> >
> >
> > > This will make things easier, technically.
> >
> >
> > It would make things much more difficult, as forgotten, unused, and
> > stale accounts would gum up the works, requiring a much larger amount of
> > manual intervention than the legitimate disputes.
> >
>
>
> I see. The main goal is to eliminate the stale/inactive account.
> But the automated selection will also impact the non-stale account.
>
> It should have a way to stop the automated selection of a specific
> username, if someone owning that username can show that he is not a
> stale account.
>
>
> > To make it possible for the system to actually work, we use an automated
> > selection for the global account, which can be overridden manually if
> > and when specific people require it.
>
>
> Can people request to stop the automated selection and stop the
> creation of global account of their username by another party?
> Especially, when their account lose in the automated selection to
> another party.
> This request will be an obvious evidence that those account is not stale.
>
> There should be a chance for them to show this evidence within some period.
>
> There are ways to automatically and easily determine that the account
> is not stale,
>
> 1. If one is trying to use his account to perform a merge, but fail to
> get the global account (since he lose in the automated selection),
> this will be another obvious evidence that the account is not stale.
> Then the creation of the global account by the other party should be
> suppressed, and notify a message like "There's non-stale, conflicting
> account using this username, then the global account creation for this
> username is deferred".
>
> 2. If the account have just recently edited the wiki page, this is
> another evidence. If at least two subsets of account using a same
> username have recently edited some wiki page, then suppress the global
> account creation of that username.
>
> While there's currently no way to determine who should mostly deserve
> to get the global account, to defer the automated selection of that
> username is the most compromising thing.
>
>
> There're three main concerns that must be taken carefully and peacefully,
> I. Eliminate only the really stale account
> II. Don't force rename/remove the local non-stale account
> III. Who should most deserve to register for the global account?
>
> For the issues I and II, I would like to give some examples of marking the
> account as non-stale,
> 1. Mr.A own both user123(a)fr.wikipedia and user123(a)fr.wikibooks
> 2. Both user123(a)fr.wikipedia and user123(a)fr.wikibooks have the same
> email and password.
> 3. If user123(a)fr.wikipedia has recently edited a page, but
> user123(a)fr.wikibooks never edit any page.
> 4. Then both user123(a)fr.wikipedia and user123(a)fr.wikibooks will be
> marked as non-stale (eventhough user123(a)fr.wikibooks never edit), and
> will never be forced to be renamed/removed, forever (if he does not,
> later, try to be an impostor).
> 5. In another case, if user456(a)fr.wikipedia have tried merging, but
> lose the global account selection to another subset of user456. Then
> all acounts in the same subset of user456(a)fr.wikipedia (those having
> same email/password) will be marked as non-stale, and never be forced
> rename/remove.
> 6. The accounts in one subset will be removed if (and only if) all
> accounts in that subset appear to never edit any page.
>
> Mr.A rightfully deserve to own all of his local accounts, since he is non-stale.
> This will be very peaceful, IMO.
>
> Now, let's consider the issue III,
>
> III. While every non-stale persons rightfully and peacefully own their
> existing local accounts, who should most deserve to register for the
> global account?
>
> In other words, who should most deserve to gain control of the rest of
> unregistered account?
>
> Let's consider this,
> 1. Mr.A and Mr.B own user123@fr and user123@ja, respectively.
> 2. user123 on the rest of wikis (
> user123@{en,zh,de,nl,...,meta,commons} ) have not yet been registered.
> 3. Both Mr.A and Mr.B are non-stale user.
> 4. The question is, between Mr.A and Mr.B, who deserve to get all
> accounts on the rest of those wikis?
>
> 5. While currently there's no any automated measurement that is fair
> and peaceful in all cases; then just simply give the global account to
> the first one who firstly perform the merge (on that username).
> 5.1 That is, if Mr.A appear to perform the merge before Mr.B, Mr.A
> will immediately get the global account.
> 5.2 On the other hand, if Mr.B perform the merge before Mr.A, Mr.B
> will get the global account.
> 5.3 Note that, the only non-stale subset (as marked by the
> automated measurement mentioned above) will be allowed the perform the
> merge.
>
> 6. This is the most simple and peaceful way. I think almost everyone
> can accept this, and can aware of the limitation of the system and of
> people who implement it.
> 7. Sysop (especially, the local sysop) should NOT have more right or
> chance to get the global account than the normal user. The wikimedia
> pioneer, developer, founder, and co-founder may be the exceptions.
>
> With this approach,
>
> 1. This will make things easier, technically, since no need to run any
> automated selection.
> 2. The conversion will go without worrying about any stale account
> concern. Stale account can still be eliminated.
>
> 3. The account that firstly appear to perform the merge will be
> implicitly proving that he is non-stale account, and deserve to get
> the global account. (This measurement may vary; depending on the
> judgement that we will permit the subset that have never edited, to
> get the global account or not)
> 4. This thing is equivalent to registering for all new unregistered
> accounts on the rest of wikis, that the first one will deserve to get
> those accounts (if he is not trying to be an impostor). The only
> difference is that, one who not owning any local account of that
> username, will not be allowed to get the rest.
> 5. The first one will deserve, since everyone in the party (that own
> the local account), have not yet own the global account. According to
> the above example, both Mr.A and Mr.B only own his local account, no
> one own user123@global yet.
> 6. Yes, this is to apply the first-come-first-serve (FCFS) in
> registering for the username on the rest of those unregistered wikis.
> Under current limitation, this is very reasonable.
> 7. While, there may be some little chances that the global account is
> given to the impostor, but it will be at manageable level, if we can
> always revoke or rename that global account later.
>
> 8. No one will be forced to rename his account. He just lose the
> right to create new account of the same username in the rest of the
> unregistered wikis. The winner just get the right for the username on
> the rest of those wikis.
> 9. Every party will happy with or can accept this, since they will not
> lose any registered account. The worst case is that, they just lose
> the chance to create new accounts on the rest. (Before the FCFS
> start, they could go to register for local account on the wikis that
> they really not want to lose the right for their desired username on
> those wikis in the future (if they lose in the FCFS))
>
> Before starting FCFS, we should announce this to everyone, for them to
> have chance to prepare themselves. For example, to register the
> username on the wikis that they not want to lose. Mr.A may begin to
> register all of user123(a)fr.*, while Mr.B will register for all of
> user123(a)ja.*.
>
---------- Forwarded message ----------
From: Ademar Aguiar <ademar.aguiar(a)fe.up.pt>
Date: Tue, Apr 15, 2008 at 11:06 PM
Subject: WikiSym 2008: Call for Submissions (3 weeks to deadline on May 3rd)
To: foundation-l-owner(a)lists.wikimedia.org
[apologize for eventual duplicates]
*************************************************************
CALL FOR PAPERS
*************************************************************
W i k i S y m 2 0 0 8
The International Symposium on Wikis
http://www.wikisym.org/ws2008/
September 8-10, 2008
Porto, Portugal
In-cooperation with ACM SIGWEB * ACM-DL Archived
*3 weeks left for submissions deadline*
*************************************************************
A gentle reminder to inform that the deadline for submitting research
papers, practitioner reports, workshops, panels, and tutorials is due in
*3 weeks*.
Please visit our website at http://www.wikisym.org/ws2008/ for more
information or contact the chairs, Ademar Aguiar and Mark Bernstein
through chair(a)wikisym.org.
Best Regards,
Mark Bernstein Ademar Aguiar
Eastgate Systems University of Porto
Program Chair Conference Chair
~ ~ ~
IMPORTANT DATES
* May 3rd: submissions deadline for research papers,
practitioner reports, workshops, panels, and tutorials
* May 17th: notifications for workshop submissions
* June 11th: submissions deadline for posters, demos,
and DoctoralSpace proposals
* June 25th: notifications for research papers, practitioner reports,
panels, tutorials, DoctoralSpace proposals, posters
and demos
* July 19th: final revised versions are due
* Sept 8th-10th: WikiSym 2008 days
~ ~ ~
SYMPOSIUM COMMITTEE
Conference: Ademar Aguiar, INESC Porto, University of Porto, Portugal
Program: Mark Bernstein, Eastgate Systems, USA
Honorary: Ward Cunningham, About Us, USA
Workshops & Panels: Andrea Forte, Georgia Institute of Technology, USA
OpenSpace: Ted Ernst, About Us, USA
WikiFest: Stewart Mader, WikiPatterns.org, Atlassian, Australia;
Uri Dekel, Carnegie Mellon University, USA
Tutorials: Marc Laporte, TikiWiki.org, Canada
Posters and Demos: Martin Cleaver, Blended Perspectives, Canada
Treasurer and Sponsorships: Dirk Riehle, SAP Research, SAP Labs LLC, USA
Publicity: Alain Désilets, National Research Council of Canada;
Marissa Hoftiezer, Carleton University, Canada
Web: Nuno Flores, University of Porto, Portugal
PROGRAM COMMITTEE
Mark Bernstein, Eastgate Systems, USA (Chair)
Phoebe Ayers, University of California at Davis, USA
Robert Biddle, Carleton University, Canada
Dan Bricklin, Software Garden, USA
Amy Bruckman, Georgia Institute of Technology, USA
Thomas Burg, Socialware, Austria
Ward Cunningham, About Us, USA
Chris Dent, Peermore, Ltd., United Kingdom
Alain Désilets, National Research Council of Canada
Lilia Efimova, Telematica Instituut, The Netherlands
Ted Ernst, About Us, USA
Andrea Forte, Georgia Institute of Technology, USA
Frank Fuchs-Kittowski, Fraunhofer-Institut für Software und
Systemtechnik, Germany
Susan Herring, Indiana University, Bloomington, USA
Samuel J. Klein, One Laptop Per Child, USA
George Landow, Brown University, USA
Helmut Leitner, WikiService, Austria
Stewart Mader, Atlassian, Australia/USA
Sky Marsen, Victoria University of Wellington, New Zealand
Cathy Marshall, Microsoft Research, USA
J. Nathan Matias, Cambridge University, United Kingdom
Paulo Merson, Software Engineering Institute, USA
Adrian Miles, Royal Melbourne Institute of Technology, Australia
David Millard, University of Southampton, United Kingdom
Stuart Moulthrop, University of Baltimore, USA
James Noble, Victoria University of Wellington, New Zealand
Dirk Riehle, SAP Research, SAP Labs LLC, USA
Scott Rosenberg, cofounder, Salon, USA
Jeremy Ruston, BT, United Kingdom
Sébastien Paquet, UQAM-Teluq, Canada
Christoph Sauer, Hochschule Heilbronn, Germany
Frank Shipman, Texas A&M, USA
Ingy döt Net, SocialText, USA
== Negotiation for consent ==
Would it be possible to let the conflicting users to resolve the
conflict by themselves, not by the decision of the automatic system
using edit-count?
The renaming of username will be made on their consent.
Example,
1. user123(a)fr.wikipedia and user123(a)ja.wikipedia is owned by different
person, Mr. A and Mr. B.
2. user123(a)fr.wikipedia and user123(a)ja.wikipedia will talk together to
make the final agreement that who will own the user name user123, and
who will be renamed.
3. If the final agreement is that Mr. A will own user123, then Mr. B
will, by himself, rename all of user123 username that he currently
possess.
4. If they can't find any final agreement, then user123 will never be
merged forever, or until they can make the agreement in anytime later.
The conflicting status will be held until they can make the
agreement.
5. In the case that Mr. B is an inactive user that Mr. A can't even
contact to discuss for the agreement, there will be some expire time
(may be one year) that, if Mr. B not response before this expire time,
user123 of Mr. B will be forced to be renamed.
5.1 There will be some mechanism to let Mr. B to leave a message that
he agree for his user to be renamed or not.
5.2 If Mr. B leave the message "not agree", he must talk to Mr. A
until they meet the same agreement.
5.3 If Mr. B not leave the message before the expire time, Mr. A can
force renaming of Mr. B account.
== Unify by language ==
Apart from the above solution, I would like to purpose the less
conflict solution.
To merge the user accounts by language.
Example,
* user123 on fr.wikipedia.org, fr.wiktionary.org, fr.wikibooks.org,
fr.wik*.org will be merged
* user123 on ja.wikipedia.org, ja.wiktionary.org, ja.wikibooks.org,
ja.wik*.org will be merged
* user123 on fr.wikipedia.org and ja.wikipedia.org won't be merged, so
that user123(a)fr.* and user123(a)ja.* will be separated.
1. This will make much less conflict than unifying all language.
1.1 Most conflicts in non-english wiki is the conflicting of user
between diffenrent language.
1.2 Even on the first-come-first-serve (FCFS) basis, this still result
in few conflict. While it look very unreasonable when the first
registered user will suddenly gain control for wikis on all languages,
it is more reansonble when FCFS is used only among the same language,
since it cover not too much wiki websites.
2. Most users will not be likely to actively edit non-trivial contents
in more than one or two languages. And it does not take too much
energy for one person to maintain their user
account/preference/watchlist in only two or three languages.
3. Most users will tend to agree to loss their username (if conflict
with others) on their non-primary language that they not actively edit
or contribute only trivial contents.
4. Even the new registered user (after this unify) will only get the
accounts of the same username on wikis of the same language. They
will not get accounts on all languages. Why let FCFS users to reserve
the control on wikis of hundred languages that most of them are
unlikely to edit or taking any attention? Unifying all languages is
an overuse.
=== Account in wiki commons ===
The only problem is that, wiki commons will be merged with which language?
* commons --> en.*, fr.*, ja.* ?
* Let the person who own user account on commons to choose the
language that will be merged with commons?
* Or the person on the language with most edit-count will get username
on commons?
* Or let the users to negotiage for the agreement by themselves?
== Public hearing ==
However, until now, why not have any poll, or any public hearing,
about this topic, from wikipedia community?
>
> Message: 2
> Date: Mon, 15 Oct 2007 09:17:00 -0400
> From: "Jay R. Ashworth" <jra(a)baylink.com>
> Subject: Re: [Wikitech-l] Primary account for single user login
> To: wikitech-l(a)lists.wikimedia.org
> Message-ID: <20071015131700.GB21934(a)cgi.jachomes.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Oct 14, 2007 at 10:54:36PM +0100, Thomas Dalton wrote:
> > How about we do away with usernames altogether and just give everyone
> > numbers? Works for the Borg...
>
> Could I have 7 of 9?
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth Baylink jra(a)baylink.com
> Designer The Things I Think RFC 2100
> Ashworth & Associates http://baylink.pitas.com '87 e24
> St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 15 Oct 2007 12:37:01 -0400
> From: Anthony <wikimail(a)inbox.org>
> Subject: Re: [Wikitech-l] Primary account for single user login
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <71cd4dd90710150937m133e45e0hea9828d8f7ff08cc(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 10/12/07, Rob Church <robchur(a)gmail.com> wrote:
> > I have noticed a worrying trend where members of the community are
> > leaping up and saying, "well, it should be done like this, not like
> > that", which is a discussion that should have been held several years
> > ago.
>
> The thing is, the discussion *was* had several years ago. See the
> thread entitled "Single login - decision 2004" on foundation-l. And
> it seems that most people discussing it there, including Erik, Jimbo,
> Jamesday, Kate, and Daniel Mayer, said that they'd prefer not to
> rename any accounts.
>
> Angela and Ant commented that they'd like for there to be a poll.
> AFAIK there never was such a poll.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 15 Oct 2007 18:39:05 +0100
> From: "Thomas Dalton" <thomas.dalton(a)gmail.com>
> Subject: Re: [Wikitech-l] Primary account for single user login
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <a4359dff0710151039k67013bd2yb12de9ecc5e3c817(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> > The thing is, the discussion *was* had several years ago. See the
> > thread entitled "Single login - decision 2004" on foundation-l. And
> > it seems that most people discussing it there, including Erik, Jimbo,
> > Jamesday, Kate, and Daniel Mayer, said that they'd prefer not to
> > rename any accounts.
> >
> > Angela and Ant commented that they'd like for there to be a poll.
> > AFAIK there never was such a poll.
>
> You can't do it without renaming accounts. It would be pointless. Why
> have a single account per person if they all have different names?
> It's not really even a single account, since accounts are pretty much
> defined by their names (yes, there is a numerical id in the database,
> but only developers care about it - and I don't think that id would be
> the same anyway).
>
> You can only have a poll if there are multiple options. Edit counts is
> the only option I've seen anyone propose that stands a chance of
> working.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 15 Oct 2007 13:07:01 -0600
> From: Daniel Cannon <cannon.danielc(a)gmail.com>
> Subject: Re: [Wikitech-l] Primary account for single user login
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Message-ID: <4713BA55.3030407(a)gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Anon Sricharoenchai 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.
>
> One point worth considering: Active users will, in the vast majority of
> cases, specify an e-mail address for their account. If these are two
> different, yet equivocally active users, even with the same username,
> they will most likely specify unique e-mail addresses. As such, and
> correct me if this has changed, the accounts will not be merged and
> treated as the same account, at least not without contacting both users
> first to find a resolution. If they have not specified an e-mail
> address, then either the accounts will not be merged or, if the accounts
> are eventually merged, the users will be more than capable of contacting
> Brion or another member of Wikimedia's technical staff to work out a
> resolution.
>
> > 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.
>
> This approach seems even more arbitrary than the edit-count approach.
> Consider that almost every Wikimedia project has a User:I They are most
> likely *all* different individuals. Why should the first registered
> User:I suddenly contain control and attribution for all of the other
> User:I's out there?
>
> Naturally, the editcount approach does not present a much better
> solution to this problem, but since almost User:I's except for the one
> on enwiki have been virtually deceased, it seems appropriate for
> enwiki's User:I to be User:I on all projects. The conflict practically
> fails to exist if the other User:I's have specified e-mail addresses, as
> they can then be contacted to work out a resolution.
>
> >
> > 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.
>
> Idealism is a nice world to live in. Unfortunately nothing about SUL is
> ideal. It's taking nearly a decade worth of history on hundreds (if not
> now thousands) of sites, containing an uncountable number of conflicts
> and questions about who is who and what is what, and attempting to glue
> them together in to one unified Wikimedia. Regardless of what approach
> is taken, this is going to be messy and cause a lot of headaches. Thus,
> the approach that is the most likely to minimize these headaches and
> this mess, namely the editcount-based solution, has been chosen.
>
> > 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.
>
> And the detriment of a quite inactive user who did not even feel the
> need to specify an e-mail address now having to go by a different
> username is ...? Naturally, accreditation issues can be quite easily
> resolved by developers, and no user is going to be revoked of his
> technical rights incorrectly nor is another user going to suddenly
> obtain ungranted rights on any project. As such, I fail to see what the
> real concern here is.
>
> - --
> Daniel Cannon (AmiDaniel)
>
> http://amidaniel.com
> cannon.danielc(a)gmail.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHE7pUFRAT5u/mSaMRAgiSAJ0QHkDBeA705+21DM5MrNjj8H1nhgCgh4qC
> Bs+zvBtsJb2nCxnIY/iYYug=
> =mWgD
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 15 Oct 2007 15:45:36 -0400
> From: Anthony <wikimail(a)inbox.org>
> Subject: Re: [Wikitech-l] Primary account for single user login
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <71cd4dd90710151245s386ef599n3c4cab8b81b79797(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 10/15/07, Thomas Dalton <thomas.dalton(a)gmail.com> wrote:
> > > The thing is, the discussion *was* had several years ago. See the
> > > thread entitled "Single login - decision 2004" on foundation-l. And
> > > it seems that most people discussing it there, including Erik, Jimbo,
> > > Jamesday, Kate, and Daniel Mayer, said that they'd prefer not to
> > > rename any accounts.
> > >
> > > Angela and Ant commented that they'd like for there to be a poll.
> > > AFAIK there never was such a poll.
> >
> > You can't do it without renaming accounts.
>
> Depends on what it is you're doing.
>
> > It would be pointless. Why
> > have a single account per person if they all have different names?
>
> Presumably at some point (maybe decades from now at the current rate)
> there are going to be shared preferences, shared watchlists, maybe
> even single sign on. In fact, until Single User Login was redefined
> to mean renaming of accounts, the whole point of it was supposed to be
> to prepare for these sorts of things.
>
> > You can only have a poll if there are multiple options. Edit counts is
> > the only option I've seen anyone propose that stands a chance of
> > working.
> >
> http://meta.wikimedia.org/wiki/Single_login_poll
>
> All three options would work.
>
>
there are some things that simply cannot be public. this is one of those
----- Original Message ----
From: Thomas Dalton <thomas.dalton(a)gmail.com>
To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>
Sent: Tuesday, April 15, 2008 10:53:25 AM
Subject: Re: [Foundation-l] Confidentiality agreement with FSF
On 15/04/2008, Chad <innocentkiller(a)gmail.com> wrote:
> Maybe they asked nicely and Erik feels like honoring a
> relatively simple request?
So being nice to the FSF takes precedence over transparency? That
seems like some seriously messed up priorities to me.
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
i would assume that should say Director, Senior Officer. This was meant to be a talking piece
----- Original Message ----
From: Dan Rosenthal <swatjester(a)gmail.com>
To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>
Sent: Sunday, April 13, 2008 6:48:09 PM
Subject: Re: [Foundation-l] Future board meeting (5-7 april 08)
No. For one thing, what is a "directory senior officer"? For another,
it does not address independent contractors. For a third, it does not
address the over-broadness of the "shall not...make any statement
that....is derogatory of Employer". Provision IV's first clause is
unnecessary, as the agreement would not supersede US laws anyway.
-dan
On Apr 13, 2008, at 8:38 PM, Geoffrey Plourde wrote:
> Is this better?
>
>
> NON-DISPARAGEMENT AND CONSIDERATION.
> I. Both Employer and Employee agree that the free and open exchange
> of ideas and information among employees, contractors, and agents of
> the Foundation is to be encouraged.
>
> II. Employee agrees that, during the term of employment and for
> three years thereafter, Employee shall not, in any communications
> with the press or other media, or any customer, client or supplier
> of company, or any of company affiliates, ridicule or make any
> statement that personally disparages or is derogatory of Employer or
> its affiliates or any of their respective directors, trustees, or
> senior officers.
>
> III. Additionally, and in consideration of Employee's covenants in
> this agreement, no directory senior officer of Employer or member of
> the Board of Trustees of the Employer will, during the same time
> period, personally criticize, ridicule or make any statement that
> personally disparages or is derogatory of Employee.
>
> IV. No provision of this agreement shall be considered to supersede
> the whistleblower protection laws of the United States of America
> and the whistleblower protection policy of this Organization.
>
> V. No provision of this agreement shall be considered to preclude
> complaints to appropriate supervisory personnel
>
> ----- Original Message ----
> From: Dan Rosenthal <swatjester(a)gmail.com>
> To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org
> >
> Sent: Sunday, April 13, 2008 5:15:16 PM
> Subject: Re: [Foundation-l] Future board meeting (5-7 april 08)
>
> Agree. That's a godawful policy. For instance, "shall not....make any
> statement that ....is derogatory of employer" means that they cannot
> say "Wikimedia Foundation is not good at this". The reciprocal
> agreement is just as bad. For instance, it only prevents "directory
> senior officer[s] of Employer or member[s] of the Board of Trustees"
> from criticizing the employee. It does not prevent, for instance,
> independent contractors from being critical and disparaging of
> employees, something that, according to some accounts that I've heard,
> has been an issue before.
>
> -Dan
> On Apr 13, 2008, at 7:40 PM, Thomas Dalton wrote:
>
>>> - begin quote -
>>> NON-DISPARAGEMENT AND CONSIDERATION. Both Employer and Employee
>>> agree that the free and open exchange of ideas and information
>>> among employees,
>>> contractors, and agents of the Foundation is to be encouraged.
>>> Employee agrees that, during the term of employment and for three
>>> years thereafter, Employee shall not, in any
>>> communications with the press or other media, or any customer,
>>> client
>>> or supplier of
>>> company, or any of company affiliates, ridicule or make any
>>> statement
>>> that personally
>>> disparages or is derogatory of Employer or its affiliates or any of
>>> their respective directors,
>>> trustees, or senior officers. Additionally, and in consideration of
>>> Employee's covenants in
>>> this agreement, no directory senior officer of Employer or member of
>>> the Board of Trustees
>>> of the Employer will, during the same time period, personally
>>> criticize, ridicule or make any
>>> statement that personally disparages or is derogatory of employee.
>>> - end quote -
>>
>> That's lawyerspeak for "You mustn't say bad things about your boss
>> (and vice versa)." I would never have signed that. It doesn't even
>> acknowledge the Whistleblowing policy, which is directly contradicts
>> (presumably that policy takes precedence, but I would have expected
>> it
>> to be made explicit). The Whistleblowing policy only applies if what
>> you're complaining about is actually illegal. If you just think your
>> boss has been doing an appalling job, you're not allowed to do
>> anything about it. Saying untrue, or purely hurtful things is clearly
>> unacceptable, but anyone should be able to stand up and tell the
>> truth
>> as they see it.
>>
>> _______________________________________________
>> foundation-l mailing list
>> foundation-l(a)lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/
>> foundation-l
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> foundation-l mailing list
> foundation-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com