Carcharoth | 1 May 2010 01:11

Re: [Foundation-l] Flagged Protection update for April 29

On Fri, Apr 30, 2010 at 10:51 PM, William Pietri <william <at> scissor.com> wrote:
> On 04/30/2010 01:34 PM, Gregory Maxwell wrote:
>>> but the general point
>>> >  remains -- you can set a cookie for an unregistered user and it will
>>> >  work as you'd like, causing the user to skip the Squid cache on all
>>> >  pages until the cookie expires.
>>>
>> This already happens when users edit.  Otherwise anons would never be
>> able to get the new messages indicator.
>
>
> That's good to know. I'll pass this on to the team and we'll see what we
> can come up with. One question for any interested stakeholder: is this
> feature worth delaying launch to add? We have a number of nice-to-haves
> on a list to work on right after launch, so development will continue.
>
> Also, Howie Fung, the UI expert on the project comments:
>
>> We can always soften the message a bit by changing the language, color
>> and/or providing a link with an explanation.
>
> So if people have suggestions on how to improve any of that, on any
> other aspect of the current implementation, please put them here:
>
> http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:FlaggedRevs_issues

You could dangle a carrot and say "if your edit gets approved, you get a prize!"

That would certainly raise a few eyebrows.

(Continue reading)

William Pietri | 1 May 2010 01:26
Favicon
Gravatar

Re: [Foundation-l] Flagged Protection update for April 29

On 04/30/2010 04:11 PM, Carcharoth wrote:
> But seriously, the issue of encouraging people to edit is crucial.
> Those who want to edit for malicious reasons will nearly always be
> prepared to jump through hoops, and those most likely to be
> discouraged by extra hoops to jump through will include those we want
> to attract to become new and regular editors.
>
> All in all, if what Greg describes can be done, that sounds best, even
> if it seems a bit misleading.
>    

Okey doke. I have passed the request on to the team to see what they 
think of the idea and how much time it will take to implement. More news 
as it comes in.

Thanks to all for the discussion!

William

_______________________________________________
WikiEN-l mailing list
WikiEN-l <at> lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

stevertigo | 3 May 2010 01:26
Picon

Re: IPA issues

Nathan <nawrich <at> gmail.com> wrote:

> I just assumed that if IPA were widely used, someone might have
> mentioned that in previous iterations of the arguments over its use.
> Perhaps that assumption is a mistake, if the limit of research done by
> IPA advocates is cherry picking Google search results. (Of course that
> comment is unfair, but then again, so was your characterisation of my
> previous post).

Keep in mind that I, for example, share many of your misgivings with IPA.
Nevertheless I recognize, as others here do, the benefits of using a single
pronunciation scheme. Granted, pronunciation is typically placed low on
most people's lists as far as language acquisition is concerned. In truth
it's not that low at all: Proper pronunciation of words in a new language
opens doors for new speakers.

> Even the IPA article mentions that EFL references use pronunciation
> guides.

I might agree to using a second standard, if that second standard was actually
a standard. It is instead something we cobbled together based on English.

My original premise, again, was that IPA be used across all wikis. If
its the in
fact the international standard that linguists claim it to be, then
why can't it be
used internationally. My suspicion may surprise other critics here in that I
see IPA as being not as international at it would like to be.

Still I favor of using a standard scheme like IPA accross all language wikis.
(Continue reading)

Anthony | 3 May 2010 02:05

Flagged protection and patrolled revisions

I've been out of the loop since January-ish, so I was pleased to see
that some headway has been made on implementing FlaggedRevs. I see
that a two-month trial on enwiki has been approved by the community:

* http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Poll

But I also see that the implementation has been languishing in
flaggedrevs.labs.wikimedia.org pretty much since then. Mutterings on
foundation-l suggest that we're close to a finished product that can
be taken to trial on enwiki, with William Pietri from the tech team
saying this week that his "understanding is that [it] is almost done".

At risk of seeming impatient, my question is this: exactly _how_ close
are we? I'm quite certain that if the extension was installed today,
by tomorrow our community would have the interface and system-message
problems ironed out. What takes a team of ten or so a few months to
perfect would take a team of hundreds much shorter, surely?

We've waited so long for FlaggedRevs. I'm now struggling to see what
the delay is. Hoping that somebody who is a bit more knowledgeable on
this can provide an update.

AGK

_______________________________________________
WikiEN-l mailing list
WikiEN-l <at> lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

(Continue reading)

William Pietri | 3 May 2010 07:28
Favicon
Gravatar

Re: Flagged protection and patrolled revisions

On 05/02/2010 05:05 PM, Anthony wrote:
> But I also see that the implementation has been languishing in
> flaggedrevs.labs.wikimedia.org pretty much since then. Mutterings on
> foundation-l suggest that we're close to a finished product that can
> be taken to trial on enwiki, with William Pietri from the tech team
> saying this week that his "understanding is that [it] is almost done".
>
> At risk of seeming impatient, my question is this: exactly_how_  close
> are we?

A very reasonable question. You can see the pertinent data here:

http://www.pivotaltracker.com/projects/46157

For the question you're asking, the "done" pane is useful to open.

Based strictly on the last few weeks of completed work and the estimates 
for the upcoming work, the week of May 24 is the current extrapolation. 
I would like to think it'll come sooner than that (as our progress in 
terms of units completed was faster earlier), and there's a possibility 
that it will come later, but I'd be surprised if it's much later.

Just to be clear, what I was referring to in the quote above, where I 
told Tim that something was almost done, is this:

http://www.pivotaltracker.com/story/show/1983720

I understand there's just a bit of work left there, but we're mainly 
focused on the UI display issue at the moment.

(Continue reading)

Carcharoth | 3 May 2010 17:15

Re: Flagged protection and patrolled revisions

Since it does seem very close to going live, could I ask if plans have
been made for how to handle announcing the arrival of this feature and
any post-implementation problems? Hopefully there won't be any or
many, but are there plans ranging from "rollback completely if things
go awfully wrong" to "make adjustments as needed and be responsive to
concerns raised"?

And how much input exactly will ordinary editors have
post-implementation? Is the interface flexible and can be changed by
editors or admins, and which bits can only be tweaked by developers
(either using common sense or following a community poll or Bugzilla
request or request somewhere else)? I ask this partly as someone who
(with others) may have to deal with any massive disputes or edit wars
that break out over this if some aspects of flagged revisions or its
interface are editable and changeable on-wiki (presumably in the
Mediawiki namespace, editable by admins only).

I think the ability for the community of editors and admins to make
such changes to the interface is a *good* thing, but want to be clear
exactly what is changeable and by whom, and if off-wiki requests are
needed, where to make them, and making this location and the whole
roll-out clear to people via on-wiki notices.

Presumably, an update will be made to the on-wiki pages about this
before it goes live? And there will some site notice giving some
warning? having things change mid-edit could be a bit disconcerting!

Carcharoth

_______________________________________________
(Continue reading)

Anthony | 3 May 2010 17:39

Re: Flagged protection and patrolled revisions

>edit wars that break out over this if some aspects of flagged revisions or its interface are >editable and
changeable on-wiki (presumably in the Mediawiki namespace, editable by admins >only).

I would have hoped that our project's administrators would be capable
of working on a project without resorting to edit or wheel warring.

AGK, ever the optimist.

_______________________________________________
WikiEN-l mailing list
WikiEN-l <at> lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

Nathan | 3 May 2010 18:16
Picon

Re: Flagged protection and patrolled revisions

On Mon, May 3, 2010 at 11:15 AM, Carcharoth <carcharothwp <at> googlemail.com> wrote:
> Since it does seem very close to going live, could I ask if plans have
> been made for how to handle announcing the arrival of this feature and
> any post-implementation problems? Hopefully there won't be any or
> many, but are there plans ranging from "rollback completely if things
> go awfully wrong" to "make adjustments as needed and be responsive to
> concerns raised"?
>
> And how much input exactly will ordinary editors have
> post-implementation? Is the interface flexible and can be changed by
> editors or admins, and which bits can only be tweaked by developers
> (either using common sense or following a community poll or Bugzilla
> request or request somewhere else)? I ask this partly as someone who
> (with others) may have to deal with any massive disputes or edit wars
> that break out over this if some aspects of flagged revisions or its
> interface are editable and changeable on-wiki (presumably in the
> Mediawiki namespace, editable by admins only).
>
> I think the ability for the community of editors and admins to make
> such changes to the interface is a *good* thing, but want to be clear
> exactly what is changeable and by whom, and if off-wiki requests are
> needed, where to make them, and making this location and the whole
> roll-out clear to people via on-wiki notices.
>
> Presumably, an update will be made to the on-wiki pages about this
> before it goes live? And there will some site notice giving some
> warning? having things change mid-edit could be a bit disconcerting!
>
> Carcharoth
>
(Continue reading)

Carcharoth | 3 May 2010 18:48

Re: Flagged protection and patrolled revisions

On Mon, May 3, 2010 at 4:15 PM, Carcharoth <carcharothwp <at> googlemail.com> wrote:

<snip>

> having things change mid-edit could be a bit disconcerting!

I've just remembered that in some implementations of this, almost
nothing changes (you have to actively bring pages within the new
system), and hardly anyone will notice any difference on most pages.
If that's the case, then I may be worrying over very little. But
hopefully there will be a final summary update (on-wiki) that can be
read before the new system goes live.

Carcharoth

_______________________________________________
WikiEN-l mailing list
WikiEN-l <at> lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

Gregory Maxwell | 3 May 2010 18:59
Picon
Gravatar

Re: Flagged protection and patrolled revisions

On Mon, May 3, 2010 at 12:48 PM, Carcharoth <carcharothwp <at> googlemail.com> wrote:
> On Mon, May 3, 2010 at 4:15 PM, Carcharoth <carcharothwp <at> googlemail.com> wrote:
>
> <snip>
>
>> having things change mid-edit could be a bit disconcerting!
>
> I've just remembered that in some implementations of this, almost
> nothing changes (you have to actively bring pages within the new
> system), and hardly anyone will notice any difference on most pages.
> If that's the case, then I may be worrying over very little. But
> hopefully there will be a final summary update (on-wiki) that can be
> read before the new system goes live.

What was decided on was using the protection control knobs to
selectively activate it.

Technically this means that nothing changes when this is activated. In
practice, however, I expect this means that every semi and full
protected page will be fairly quickly converted and in the main
namespace actual protection will quickly become a infrequently used
drastic measure employed only against high volume trouble making. ...
so I would expect it to hit a lot of pages rather quickly as a lot of
popular pages are semi-protected.

Hopefully the visible difference for most people will be minimal and
the primary visible effect will be that popular pages will once again
be editable for people without long established accounts.

As the software currently stands, however,  it generates some rather
(Continue reading)


Gmane