Brion Vibber | 1 Jan 02:33 2012
Picon

Re: Email notification sender

On Sat, Dec 31, 2011 at 3:32 PM, Mark A. Hershberger <
mhershberger <at> wikimedia.org> wrote:

> Thomas Dalton <thomas.dalton <at> gmail.com> writes:
>
> > Why do email notifications from Wikipedia have the sender as
> > "MediaWiki Mail"? Most Wikipedia users probably don't know what
> > "MediaWiki" is. I suggest it be changed to "Wikipedia" or "Wikipedia
> > notifications" or something like that.
>
> Please see https://bugzilla.wikimedia.org/32770 where Sam Reed says "If
> we decide what we want [$wgPasswordSenderName] to be, we can configure
> it."
>
> If you want us to set it, post what you think the "From" addresses
> should be to the bug.  Or file a new bug for setting it.
>

How about just setting it to the sitename? 'Wikipedia', 'Wikinews', etc.
As, uh, suggested already above. :)

-- brion
Brion Vibber | 1 Jan 02:46 2012
Picon

Re: Files with unknown copyright status on MediaWiki wiki

On Sat, Dec 31, 2011 at 3:21 AM, Maarten Dammers <maarten <at> mdammers.nl>wrote:

> Op 31-12-2011 11:25, K. Peachey schreef:
> > We currently have a large number of file uploads with no licensing
> > data on MW wiki! And we should really start doing something about it,
> >
> > So the floor is open! What course of action should we take?
> * Notify all uploaders with unknown copyright files
> * Sort out
> https://www.mediawiki.org/wiki/Category:Files_with_unknown_copyright_status
> * Move all good files to Commons
> * Delete all bad files
> * Disable local uploads
>
> You probably want to get some Commons users involved. This is not the
> first time this is happening.
>

I would hesitate on that -- Commons seems a highly hostile environment for
the sort of ad-hoc screenshots that we expect and use on a wiki dedicated
to software documentation and development like mediawiki.org.

-- brion
Gregory Varnum | 1 Jan 14:01 2012

Re: Files with unknown copyright status on MediaWiki wiki

I don't feel strongly about use of Commons - but have posted some MW images there myself (I think...).  Any
images used in the public domain help section I'd advocate for using there - if for no other reason than it's
more accessible to others wikis using them.  Regarding MW.org only documentation (like Manual and
extensions) - brion makes a good point about the potential problems caused by an overzealous (but well
intentioned) Commons admin cleaning up important images that are mis or incompletely labeled.

I'm glad Peachey brought this issue up.  :)  I'd be willing to join others in volunteering to sort through
these.  Sounds like the steps might be:
1. Check userpages of file's uploader to see if they have a notice there - if so - post that notice on file's page
2.  Post a notice on the talk page for uploaders of remaining files giving 2 weeks to correct (more since it's MW.org?)
3.  After the two(?) weeks - attempt to tag photos used in documentation or extensions - such as screenshots
(which I imagine are the vast majority) and remove (then delete) any images on those pages which are not
clear (logos, etc.) from those pages
4.  Any files not used in documentation (manual or extensions), explained sensibly by the uploader during
this process, or files not easily tagged are then deleted
5.  Lather, rinse and repeat in six months

Here's a template I tweaked from enWP to use on user talk pages if it helps with consistency:
https://www.mediawiki.org/wiki/Template:Unknown_copyright-notice

Also put together a project page to display the templates.  I tend to agree that for most folks using MW.org a
category should probably be enough - but if it helps a few more folks add tags...I'll give it a try.
https://www.mediawiki.org/wiki/Project:File_copyright_tags

Perhaps we should revisit the conversation of an image policy mentioned here:
https://www.mediawiki.org/wiki/Project:Fair_use_policy

There didn't seem to be consensus on a fair use policy - but the start of an actual image policy is there.

Thoughts?
(Continue reading)

Brion Vibber | 1 Jan 18:49 2012
Picon

Rolling towards 1.19... scheduling a code freeze

Happy New Year everybody -- we survived 2011 and have another wacky fun
year of MediaWiki goodness to look forward to in 2012!

As we roll over our calendars, let's not forget it's also getting towards
time to roll out another MediaWiki release. 1.19's seen a lot of
refactoring goodness, bug fixes, and improvements; we need to make sure we
can get those improvements out to the public.

I'd like us to plan for a code freeze on trunk -- at least a feature &
refactoring freeze -- starting within a few days to give us all a chance to
tidy up, catch up with code review, and prepare for deployments.

The combinations of review, testing, and actual deployments are important
parts of our quality control system; we know from past experience that long
waits between deployments have lead to poorly-tested code getting pushed
out long after they've fallen out of our collective memory, making bugs
newly discovered in them harder to find.

I believe we've got some general plans to hit deployment in February; if we
hit code slush this week or so that gives some time for everybody to catch
up on review, do more thorough testing and -- perhaps most importantly of
all -- make sure we have good documentation on what's changed and what
needs to be tested and tried out by real humans!

Note that I'm recommending a slush/freeze on trunk rather than simply
branching and doing review on the release branch because that's been hard
to manage in the past. I think we really need to concentrate on release
polish, especially making sure that we don't have unexpected regressions
and that people know what to expect has changed in the user interface and
in behavior. Even "small" features like the image rotation changes we
(Continue reading)

Petr Bena | 1 Jan 19:12 2012
Picon

grouping users - an idea for a new SUL improvement

Hi,

I think it would be cool to implement a feature which would allow
users to group all their accounts, it would be very useful for sites
like english wikipedia so that people could avoid being accused for
"sock puppetry" (using more than one account) by marking the accounts
as grouped, it is possible to create account in mediawiki so that you
can see in log that it was created by someone else, but this log is
available only for wiki where it was registered on and it's also not
possible to mark account later in case you forgot to create it in
proper way

Statistics of users would be also more accurate because you would be
able to list groups only instead of all users and you would see exact
number of users and not number of all accounts, including alternative
accounts

This group interface could allow people to group their account
anytime, the grouped accounts would be still completely separate, with
different configuration, etc. But it would allow to check how many and
which accounts someone have in a simpler way than it's now. (browsing
multiple logs isn't really easy)

My idea is that each account would implicitly have a group which would
be identical to its name, User:TestyBob would be a member of group
TestyBob but it would be possible to change this group to any existing
group, it would be of course needed to confirm this from target
account, then you would just display members of group Test and you
would see list of all accounts linked to the "main account", so you
would know who is owner, how many account they have and such. I think
(Continue reading)

Platonides | 2 Jan 00:17 2012
Picon

Re: Files with unknown copyright status on MediaWiki wiki

I considered it in the past, but left when looking at the large amount 
of files without copyright tags.
The problem of mediawiki.org is that they have many files whose 
copyright status is unknown,  but that -unlike wikipedia- were uploaded 
by there authors (with high probability).

There are old files with unactive authors which would be a pity to lose, 
screenshots including logos, files with no license by wmf employees...

However, I think it's a good time to begin being strict with the license 
of newly uploaded images.

Happy New Year!
Platonides | 2 Jan 00:27 2012
Picon

Re: grouping users - an idea for a new SUL improvement

Looks good. Although I'd rename the "member of Group:Bob" to "belongs to 
User:Bob", so you would have:
User:Bob
User:BobBot - belongs to User:Bob
User:Bob (testing) - belongs to User:Bob
User:Bob (vector skin) - belongs to User:Bob

Although this opens the can of accounts with different names on several 
wikis.
User:BobBot may belong to User:Bob everywhere but in wikis Foo, Bar and 
Baz, where Bob username was taken and he is known as 'Bob2'.
Showing that "BobBot is of Bob" may be a bit confusing as in that wiki 
Bob is a different guy (even if coherent due to usage of sul usernames).

It's not a problem to have sul Bob2 as belonging to Bob, but the local 
Bob may belong to global "Bob Smith". And if we start user groups, the 
Bob Smiths out there will ask for them to be recognised.
Maybe there could be local accounts attached to user groups separatedly 
from sul ones.
Happy Melon | 2 Jan 01:16 2012
Picon

Re: grouping users - an idea for a new SUL improvement

Basically this comes back again to the "cool... oh wait SUL" thought
process...

Way back at the dawn of CentralAuth, the whole merging accounts 'thing' was
hopefully touted as a transitionary phase, with the ultimate nirvana being
having every username on every wiki either part of a global account,
reserved for a global account, or universally available; whereupon SUL
would cease to be an issue for projects like this (User:BobBot is a
universal global account affiliated to the User:Bob global account,
everywhere).  Does anyone have any stats on how far short we are of that
goal?  As in, what fraction of accounts on all wikis are still part of the
'messy' part of SUL rather than the 'clean' part?

--HM

On 1 January 2012 23:27, Platonides <Platonides <at> gmail.com> wrote:

> Looks good. Although I'd rename the "member of Group:Bob" to "belongs to
> User:Bob", so you would have:
> User:Bob
> User:BobBot - belongs to User:Bob
> User:Bob (testing) - belongs to User:Bob
> User:Bob (vector skin) - belongs to User:Bob
>
>
> Although this opens the can of accounts with different names on several
> wikis.
> User:BobBot may belong to User:Bob everywhere but in wikis Foo, Bar and
> Baz, where Bob username was taken and he is known as 'Bob2'.
> Showing that "BobBot is of Bob" may be a bit confusing as in that wiki
(Continue reading)

Mono mium | 2 Jan 01:08 2012
Picon

Re: grouping users - an idea for a new SUL improvement

I had a related question: Is there any way to actually verify the logins of
Wikimedia users w/o username/password?

On Sun, Jan 1, 2012 at 4:27 PM, Platonides <Platonides <at> gmail.com> wrote:

> Looks good. Although I'd rename the "member of Group:Bob" to "belongs to
> User:Bob", so you would have:
> User:Bob
> User:BobBot - belongs to User:Bob
> User:Bob (testing) - belongs to User:Bob
> User:Bob (vector skin) - belongs to User:Bob
>
>
> Although this opens the can of accounts with different names on several
> wikis.
> User:BobBot may belong to User:Bob everywhere but in wikis Foo, Bar and
> Baz, where Bob username was taken and he is known as 'Bob2'.
> Showing that "BobBot is of Bob" may be a bit confusing as in that wiki
> Bob is a different guy (even if coherent due to usage of sul usernames).
>
> It's not a problem to have sul Bob2 as belonging to Bob, but the local
> Bob may belong to global "Bob Smith". And if we start user groups, the
> Bob Smiths out there will ask for them to be recognised.
> Maybe there could be local accounts attached to user groups separatedly
> from sul ones.
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l <at> lists.wikimedia.org
(Continue reading)

Mark A. Hershberger | 2 Jan 01:44 2012
Picon

Re: grouping users - an idea for a new SUL improvement 57955)

Mono mium <monomium <at> gmail.com> writes:

> I had a related question: Is there any way to actually verify the logins of
> Wikimedia users w/o username/password?

See http://toolserver.org/~magnus/tusc.php.  It verifies accounts by
asking you to edit your talk page with a hash.

There is also an OAuth proposal: https://www.mediawiki.org/wiki/OAuth

Mark.

Gmane