[Wikimedia-l] Superprotect user right, Coming to a wiki near you

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Wikimedia-l] Superprotect user right, Coming to a wiki near you

Tim Davenport
Re: Erik Möller's remark: "In general, though, let's talk. The overarching
principle we're not
going to budge on is that this process is really not acceptable:

1) The UI changes
2) A subset of users is upset and organizes a poll/vote
3) The poll/vote closes with a request to undo said UI Change and a
request is filed
4) WMF offers compromise or says no
5) A local hack is used to undo said UI change

That's no way to develop software, and that's no way to work together...."

=========

I could spend 10,000 words on this. I'll try to keep it (comparatively)
short.


The reason this dysfunctional situation develops, Erik, is because there
are no steps A, B, C, D, E, F, and G preceding #1 on the list.

As things currently stand, this is the way the software development process
at WMF seems to me to work:

* Engineers collecting paychecks obviously need something to do.
* Someone comes up with a bright idea that sounds good on paper.
* Engineers decide to make that idea a reality and start work.
* Inadequately tested software, sometimes of dubious utility, is
unilaterally imposed on volunteers.
* If new software is problematic enough, volunteers revolt by any means
necessary.
* WMF forces changes down throat of volunteers by any means necessary.

This is truly "no way to develop software" and "no way to work together."

-----

Here is the way the process SHOULD begin:

* WMF staffers, plural, identify by user names/IP addresses the 10,000 or
so very active volunteers across all projects and database them.

* WMF staffers further divide this group into coherent "types": content
writers, gnome-type copy editors, structural adapters (template people, bot
operators, etc.), quality control workers (NPP, AfD), vandal fighters,
behavioral administrators (ArbCom, Ani, the various Admin pages), and drone
bees who do nothing but Facebook-style drama mongering. Multiple categories
may apply to single individuals and this list is not necessarily exhaustive.

* Once identified, WMF staffers frequently and regularly poll very active
users in each category about WHAT THEY NEED. Different surveys for
different volunteer types.

* Software development starts ONLY when a real need is identified.

* Software should be introduced on En-WP, De-WP, or Commons ONLY when it is
Alpha-grade, debugged and ready to roll. (Test things on the smaller Wikis
first).

-----

Moreover, there should be some polling mechanism to summarize and analyze
what the 500 million or whatever readers worldwide feel that they like and
feel they are missing. "User experience" changes with primary impact on
readers rather than volunteers (such as MediaViewer) should be made with
them in mind first and foremost; editing and structural tools should be
made to actually assist the active volunteers, not created on a whim.

Sometimes the needs of the Readers and the needs of the Volunteers are
different, let us frankly say. In no case should WMF assume the views and
criticism of the latter are insignificant or wrong simply because
500,000,000 > 10,000.

Remember this because according to the same logic: 10,000 > 240.

-----

We all agree that we need a bigger pool of very active volunteers. Most
readers are never going to be very active volunteers, nor do we want them
to be, since we need specialized skill sets. Most people using the editing
software are only going to make one or a very few changes a year and they
are never going to even "see" the backstage world of Wikipedia. That is
normal and fine.

We do need expert contributors on esoteric topics and we need solid
contributors from the developing world and we need to replenish the people
doing copy editing and quality control work.

We don't need tools that nobody asked for and nobody wants shoved down our
throats just because engineers needed something to do.



240 Paid Staff + 10,000 Serious Volunteers + 500,000,000 Readers and
occasional minor contributors

Three groups with differing needs.


Tim Davenport /// "Carrite" on WP /// "Randy from Boise" on WPO
Corvallis, OR
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Gerard Meijssen-3
Hoi,
I am getting so pissed off.

Let us be realistic. The user experience sucks ... It sucks big time and
even though the "community" is comfortable with it, it impedes the use by
the people we do it all for. They are the READERS.. they are not the
editors and the least this is done for are the people who are so indignant
because their experience changes.

When you look at the last year, the biggest changes are driven by the
development for mobiles. The projections make it plain this is where our
customers will be. The existing Wikipedia with its monobook and what have
you skin will not be seen, used or be relevant to them. Our traffic is
transitioning to mobile. Editing starts to happen on mobile and if it is
not clear to the "community" that future development will be in this
direction they live under a rock or they are in denial.

Have a look at a Commons page on a mobile.. It is beyond bad and beyond
useful. With the Multimedia viewer it becomes useful. (NB there are things
in there that are brain dead but that is a different story)

WAKE UP. Our world is changing. Trying to shame the WMF development in a
different direction is counter productive, ill considered and even
destructive. When you are the "community", and when this is new to you, I
hope you will sit back for a moment and consider this.  When this does not
make a difference to you, there is always the right of departure. In my
brutal opinion we have no option but to move towards a more mobile centred
appreciation. The alternative is stagnation and irrelevance. That does not
need to happen when we accept that the world changes around us.
Thanks,
     GerardM


On 14 August 2014 17:28, Tim Davenport <[hidden email]> wrote:

> Re: Erik Möller's remark: "In general, though, let's talk. The overarching
> principle we're not
> going to budge on is that this process is really not acceptable:
>
> 1) The UI changes
> 2) A subset of users is upset and organizes a poll/vote
> 3) The poll/vote closes with a request to undo said UI Change and a
> request is filed
> 4) WMF offers compromise or says no
> 5) A local hack is used to undo said UI change
>
> That's no way to develop software, and that's no way to work together...."
>
> =========
>
> I could spend 10,000 words on this. I'll try to keep it (comparatively)
> short.
>
>
> The reason this dysfunctional situation develops, Erik, is because there
> are no steps A, B, C, D, E, F, and G preceding #1 on the list.
>
> As things currently stand, this is the way the software development process
> at WMF seems to me to work:
>
> * Engineers collecting paychecks obviously need something to do.
> * Someone comes up with a bright idea that sounds good on paper.
> * Engineers decide to make that idea a reality and start work.
> * Inadequately tested software, sometimes of dubious utility, is
> unilaterally imposed on volunteers.
> * If new software is problematic enough, volunteers revolt by any means
> necessary.
> * WMF forces changes down throat of volunteers by any means necessary.
>
> This is truly "no way to develop software" and "no way to work together."
>
> -----
>
> Here is the way the process SHOULD begin:
>
> * WMF staffers, plural, identify by user names/IP addresses the 10,000 or
> so very active volunteers across all projects and database them.
>
> * WMF staffers further divide this group into coherent "types": content
> writers, gnome-type copy editors, structural adapters (template people, bot
> operators, etc.), quality control workers (NPP, AfD), vandal fighters,
> behavioral administrators (ArbCom, Ani, the various Admin pages), and drone
> bees who do nothing but Facebook-style drama mongering. Multiple categories
> may apply to single individuals and this list is not necessarily
> exhaustive.
>
> * Once identified, WMF staffers frequently and regularly poll very active
> users in each category about WHAT THEY NEED. Different surveys for
> different volunteer types.
>
> * Software development starts ONLY when a real need is identified.
>
> * Software should be introduced on En-WP, De-WP, or Commons ONLY when it is
> Alpha-grade, debugged and ready to roll. (Test things on the smaller Wikis
> first).
>
> -----
>
> Moreover, there should be some polling mechanism to summarize and analyze
> what the 500 million or whatever readers worldwide feel that they like and
> feel they are missing. "User experience" changes with primary impact on
> readers rather than volunteers (such as MediaViewer) should be made with
> them in mind first and foremost; editing and structural tools should be
> made to actually assist the active volunteers, not created on a whim.
>
> Sometimes the needs of the Readers and the needs of the Volunteers are
> different, let us frankly say. In no case should WMF assume the views and
> criticism of the latter are insignificant or wrong simply because
> 500,000,000 > 10,000.
>
> Remember this because according to the same logic: 10,000 > 240.
>
> -----
>
> We all agree that we need a bigger pool of very active volunteers. Most
> readers are never going to be very active volunteers, nor do we want them
> to be, since we need specialized skill sets. Most people using the editing
> software are only going to make one or a very few changes a year and they
> are never going to even "see" the backstage world of Wikipedia. That is
> normal and fine.
>
> We do need expert contributors on esoteric topics and we need solid
> contributors from the developing world and we need to replenish the people
> doing copy editing and quality control work.
>
> We don't need tools that nobody asked for and nobody wants shoved down our
> throats just because engineers needed something to do.
>
>
>
> 240 Paid Staff + 10,000 Serious Volunteers + 500,000,000 Readers and
> occasional minor contributors
>
> Three groups with differing needs.
>
>
> Tim Davenport /// "Carrite" on WP /// "Randy from Boise" on WPO
> Corvallis, OR
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Pine W
Gerard,

I believe that the disputes about MediaViewer are mostly about the desktop
platform's version, as most editors use the desktop platform to edit.

In general terms, I have yet to hear someone say that the Mobile platform
is a low development priority. I am familiar with Mobile-l. Mobile
development has a long road ahead of it but I feel Mobile is overall moving
in the right direction. In my experience, Mobile development has good
interpersonal harmony among participants, and everyone is hoping to convert
a portion of mobile app users to new contributors.

Pine
On Aug 14, 2014 11:58 PM, "Gerard Meijssen" <[hidden email]>
wrote:

> Hoi,
> I am getting so pissed off.
>
> Let us be realistic. The user experience sucks ... It sucks big time and
> even though the "community" is comfortable with it, it impedes the use by
> the people we do it all for. They are the READERS.. they are not the
> editors and the least this is done for are the people who are so indignant
> because their experience changes.
>
> When you look at the last year, the biggest changes are driven by the
> development for mobiles. The projections make it plain this is where our
> customers will be. The existing Wikipedia with its monobook and what have
> you skin will not be seen, used or be relevant to them. Our traffic is
> transitioning to mobile. Editing starts to happen on mobile and if it is
> not clear to the "community" that future development will be in this
> direction they live under a rock or they are in denial.
>
> Have a look at a Commons page on a mobile.. It is beyond bad and beyond
> useful. With the Multimedia viewer it becomes useful. (NB there are things
> in there that are brain dead but that is a different story)
>
> WAKE UP. Our world is changing. Trying to shame the WMF development in a
> different direction is counter productive, ill considered and even
> destructive. When you are the "community", and when this is new to you, I
> hope you will sit back for a moment and consider this.  When this does not
> make a difference to you, there is always the right of departure. In my
> brutal opinion we have no option but to move towards a more mobile centred
> appreciation. The alternative is stagnation and irrelevance. That does not
> need to happen when we accept that the world changes around us.
> Thanks,
>      GerardM
>
>
> On 14 August 2014 17:28, Tim Davenport <[hidden email]> wrote:
>
> > Re: Erik Möller's remark: "In general, though, let's talk. The
> overarching
> > principle we're not
> > going to budge on is that this process is really not acceptable:
> >
> > 1) The UI changes
> > 2) A subset of users is upset and organizes a poll/vote
> > 3) The poll/vote closes with a request to undo said UI Change and a
> > request is filed
> > 4) WMF offers compromise or says no
> > 5) A local hack is used to undo said UI change
> >
> > That's no way to develop software, and that's no way to work
> together...."
> >
> > =========
> >
> > I could spend 10,000 words on this. I'll try to keep it (comparatively)
> > short.
> >
> >
> > The reason this dysfunctional situation develops, Erik, is because there
> > are no steps A, B, C, D, E, F, and G preceding #1 on the list.
> >
> > As things currently stand, this is the way the software development
> process
> > at WMF seems to me to work:
> >
> > * Engineers collecting paychecks obviously need something to do.
> > * Someone comes up with a bright idea that sounds good on paper.
> > * Engineers decide to make that idea a reality and start work.
> > * Inadequately tested software, sometimes of dubious utility, is
> > unilaterally imposed on volunteers.
> > * If new software is problematic enough, volunteers revolt by any means
> > necessary.
> > * WMF forces changes down throat of volunteers by any means necessary.
> >
> > This is truly "no way to develop software" and "no way to work together."
> >
> > -----
> >
> > Here is the way the process SHOULD begin:
> >
> > * WMF staffers, plural, identify by user names/IP addresses the 10,000 or
> > so very active volunteers across all projects and database them.
> >
> > * WMF staffers further divide this group into coherent "types": content
> > writers, gnome-type copy editors, structural adapters (template people,
> bot
> > operators, etc.), quality control workers (NPP, AfD), vandal fighters,
> > behavioral administrators (ArbCom, Ani, the various Admin pages), and
> drone
> > bees who do nothing but Facebook-style drama mongering. Multiple
> categories
> > may apply to single individuals and this list is not necessarily
> > exhaustive.
> >
> > * Once identified, WMF staffers frequently and regularly poll very active
> > users in each category about WHAT THEY NEED. Different surveys for
> > different volunteer types.
> >
> > * Software development starts ONLY when a real need is identified.
> >
> > * Software should be introduced on En-WP, De-WP, or Commons ONLY when it
> is
> > Alpha-grade, debugged and ready to roll. (Test things on the smaller
> Wikis
> > first).
> >
> > -----
> >
> > Moreover, there should be some polling mechanism to summarize and analyze
> > what the 500 million or whatever readers worldwide feel that they like
> and
> > feel they are missing. "User experience" changes with primary impact on
> > readers rather than volunteers (such as MediaViewer) should be made with
> > them in mind first and foremost; editing and structural tools should be
> > made to actually assist the active volunteers, not created on a whim.
> >
> > Sometimes the needs of the Readers and the needs of the Volunteers are
> > different, let us frankly say. In no case should WMF assume the views and
> > criticism of the latter are insignificant or wrong simply because
> > 500,000,000 > 10,000.
> >
> > Remember this because according to the same logic: 10,000 > 240.
> >
> > -----
> >
> > We all agree that we need a bigger pool of very active volunteers. Most
> > readers are never going to be very active volunteers, nor do we want them
> > to be, since we need specialized skill sets. Most people using the
> editing
> > software are only going to make one or a very few changes a year and they
> > are never going to even "see" the backstage world of Wikipedia. That is
> > normal and fine.
> >
> > We do need expert contributors on esoteric topics and we need solid
> > contributors from the developing world and we need to replenish the
> people
> > doing copy editing and quality control work.
> >
> > We don't need tools that nobody asked for and nobody wants shoved down
> our
> > throats just because engineers needed something to do.
> >
> >
> >
> > 240 Paid Staff + 10,000 Serious Volunteers + 500,000,000 Readers and
> > occasional minor contributors
> >
> > Three groups with differing needs.
> >
> >
> > Tim Davenport /// "Carrite" on WP /// "Randy from Boise" on WPO
> > Corvallis, OR
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Gerard Meijssen-3
Hoi,
I am afraid you do not get the point. The point is that the desktop as we
know it is our history. It is like the Dodo; something that is best
experienced in the museum to be replaced by something contemporary in the
real world. The development of a single UI is what you should consider and
expect and it should support any platform.

What the Mediaviewer does is move us away from a cluttered unintelligible
page of data junk for those who are not initiated. It is a step towards
something intelligible that may be supported on any platform.

Yes, what you hear is people whining about their desktop experience. They
want to keep things as it is and, any argument, any approach is fine as far
as they are concerned.

Our desktop experience has improved somewhat over the years but it is all
the ballast of the past that is keeping us back. It is all the byzantine
embellishments that are so "important" to have. But really, when people
like myself refuse to edit Wikipedia because the experience is so bad you
have lost with me more than is justified by insisting on the status quo.

Ask yourself, who do we do it for and who should be able to edit.

FYI I was involved in Wikipedia before there was a Wikimania.
Thanks,
      GerardM


On 15 August 2014 10:02, Pine W <[hidden email]> wrote:

> Gerard,
>
> I believe that the disputes about MediaViewer are mostly about the desktop
> platform's version, as most editors use the desktop platform to edit.
>
> In general terms, I have yet to hear someone say that the Mobile platform
> is a low development priority. I am familiar with Mobile-l. Mobile
> development has a long road ahead of it but I feel Mobile is overall moving
> in the right direction. In my experience, Mobile development has good
> interpersonal harmony among participants, and everyone is hoping to convert
> a portion of mobile app users to new contributors.
>
> Pine
> On Aug 14, 2014 11:58 PM, "Gerard Meijssen" <[hidden email]>
> wrote:
>
> > Hoi,
> > I am getting so pissed off.
> >
> > Let us be realistic. The user experience sucks ... It sucks big time and
> > even though the "community" is comfortable with it, it impedes the use by
> > the people we do it all for. They are the READERS.. they are not the
> > editors and the least this is done for are the people who are so
> indignant
> > because their experience changes.
> >
> > When you look at the last year, the biggest changes are driven by the
> > development for mobiles. The projections make it plain this is where our
> > customers will be. The existing Wikipedia with its monobook and what have
> > you skin will not be seen, used or be relevant to them. Our traffic is
> > transitioning to mobile. Editing starts to happen on mobile and if it is
> > not clear to the "community" that future development will be in this
> > direction they live under a rock or they are in denial.
> >
> > Have a look at a Commons page on a mobile.. It is beyond bad and beyond
> > useful. With the Multimedia viewer it becomes useful. (NB there are
> things
> > in there that are brain dead but that is a different story)
> >
> > WAKE UP. Our world is changing. Trying to shame the WMF development in a
> > different direction is counter productive, ill considered and even
> > destructive. When you are the "community", and when this is new to you, I
> > hope you will sit back for a moment and consider this.  When this does
> not
> > make a difference to you, there is always the right of departure. In my
> > brutal opinion we have no option but to move towards a more mobile
> centred
> > appreciation. The alternative is stagnation and irrelevance. That does
> not
> > need to happen when we accept that the world changes around us.
> > Thanks,
> >      GerardM
> >
> >
> > On 14 August 2014 17:28, Tim Davenport <[hidden email]> wrote:
> >
> > > Re: Erik Möller's remark: "In general, though, let's talk. The
> > overarching
> > > principle we're not
> > > going to budge on is that this process is really not acceptable:
> > >
> > > 1) The UI changes
> > > 2) A subset of users is upset and organizes a poll/vote
> > > 3) The poll/vote closes with a request to undo said UI Change and a
> > > request is filed
> > > 4) WMF offers compromise or says no
> > > 5) A local hack is used to undo said UI change
> > >
> > > That's no way to develop software, and that's no way to work
> > together...."
> > >
> > > =========
> > >
> > > I could spend 10,000 words on this. I'll try to keep it (comparatively)
> > > short.
> > >
> > >
> > > The reason this dysfunctional situation develops, Erik, is because
> there
> > > are no steps A, B, C, D, E, F, and G preceding #1 on the list.
> > >
> > > As things currently stand, this is the way the software development
> > process
> > > at WMF seems to me to work:
> > >
> > > * Engineers collecting paychecks obviously need something to do.
> > > * Someone comes up with a bright idea that sounds good on paper.
> > > * Engineers decide to make that idea a reality and start work.
> > > * Inadequately tested software, sometimes of dubious utility, is
> > > unilaterally imposed on volunteers.
> > > * If new software is problematic enough, volunteers revolt by any means
> > > necessary.
> > > * WMF forces changes down throat of volunteers by any means necessary.
> > >
> > > This is truly "no way to develop software" and "no way to work
> together."
> > >
> > > -----
> > >
> > > Here is the way the process SHOULD begin:
> > >
> > > * WMF staffers, plural, identify by user names/IP addresses the 10,000
> or
> > > so very active volunteers across all projects and database them.
> > >
> > > * WMF staffers further divide this group into coherent "types": content
> > > writers, gnome-type copy editors, structural adapters (template people,
> > bot
> > > operators, etc.), quality control workers (NPP, AfD), vandal fighters,
> > > behavioral administrators (ArbCom, Ani, the various Admin pages), and
> > drone
> > > bees who do nothing but Facebook-style drama mongering. Multiple
> > categories
> > > may apply to single individuals and this list is not necessarily
> > > exhaustive.
> > >
> > > * Once identified, WMF staffers frequently and regularly poll very
> active
> > > users in each category about WHAT THEY NEED. Different surveys for
> > > different volunteer types.
> > >
> > > * Software development starts ONLY when a real need is identified.
> > >
> > > * Software should be introduced on En-WP, De-WP, or Commons ONLY when
> it
> > is
> > > Alpha-grade, debugged and ready to roll. (Test things on the smaller
> > Wikis
> > > first).
> > >
> > > -----
> > >
> > > Moreover, there should be some polling mechanism to summarize and
> analyze
> > > what the 500 million or whatever readers worldwide feel that they like
> > and
> > > feel they are missing. "User experience" changes with primary impact on
> > > readers rather than volunteers (such as MediaViewer) should be made
> with
> > > them in mind first and foremost; editing and structural tools should be
> > > made to actually assist the active volunteers, not created on a whim.
> > >
> > > Sometimes the needs of the Readers and the needs of the Volunteers are
> > > different, let us frankly say. In no case should WMF assume the views
> and
> > > criticism of the latter are insignificant or wrong simply because
> > > 500,000,000 > 10,000.
> > >
> > > Remember this because according to the same logic: 10,000 > 240.
> > >
> > > -----
> > >
> > > We all agree that we need a bigger pool of very active volunteers. Most
> > > readers are never going to be very active volunteers, nor do we want
> them
> > > to be, since we need specialized skill sets. Most people using the
> > editing
> > > software are only going to make one or a very few changes a year and
> they
> > > are never going to even "see" the backstage world of Wikipedia. That is
> > > normal and fine.
> > >
> > > We do need expert contributors on esoteric topics and we need solid
> > > contributors from the developing world and we need to replenish the
> > people
> > > doing copy editing and quality control work.
> > >
> > > We don't need tools that nobody asked for and nobody wants shoved down
> > our
> > > throats just because engineers needed something to do.
> > >
> > >
> > >
> > > 240 Paid Staff + 10,000 Serious Volunteers + 500,000,000 Readers and
> > > occasional minor contributors
> > >
> > > Three groups with differing needs.
> > >
> > >
> > > Tim Davenport /// "Carrite" on WP /// "Randy from Boise" on WPO
> > > Corvallis, OR
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Todd Allen
Gerard,

I don't think anyone is insisting on the status quo. But we do expect that
improvements be, well, better than what they improve. Breaking attribution
for our media files, or hiding it by requiring a click, is not an
"improvement". The people who created and uploaded that media deserve their
credit, and potential reusers need to see the license at once. That is not
"junk".

Developing for mobile is nice and should continue, but desktop is far from
dead. I don't even try to edit from mobile; I want my real keyboard and
monitor, not the crappy on screen one and 3" display.

What is suitable for desktop often isn't for mobile. One size fits all
won't work there, nor will "forget the desktop users". We'll have plenty of
both for the foreseeable future.
On Aug 15, 2014 3:18 AM, "Gerard Meijssen" <[hidden email]>
wrote:

> Hoi,
> I am afraid you do not get the point. The point is that the desktop as we
> know it is our history. It is like the Dodo; something that is best
> experienced in the museum to be replaced by something contemporary in the
> real world. The development of a single UI is what you should consider and
> expect and it should support any platform.
>
> What the Mediaviewer does is move us away from a cluttered unintelligible
> page of data junk for those who are not initiated. It is a step towards
> something intelligible that may be supported on any platform.
>
> Yes, what you hear is people whining about their desktop experience. They
> want to keep things as it is and, any argument, any approach is fine as far
> as they are concerned.
>
> Our desktop experience has improved somewhat over the years but it is all
> the ballast of the past that is keeping us back. It is all the byzantine
> embellishments that are so "important" to have. But really, when people
> like myself refuse to edit Wikipedia because the experience is so bad you
> have lost with me more than is justified by insisting on the status quo.
>
> Ask yourself, who do we do it for and who should be able to edit.
>
> FYI I was involved in Wikipedia before there was a Wikimania.
> Thanks,
>       GerardM
>
>
> On 15 August 2014 10:02, Pine W <[hidden email]> wrote:
>
> > Gerard,
> >
> > I believe that the disputes about MediaViewer are mostly about the
> desktop
> > platform's version, as most editors use the desktop platform to edit.
> >
> > In general terms, I have yet to hear someone say that the Mobile platform
> > is a low development priority. I am familiar with Mobile-l. Mobile
> > development has a long road ahead of it but I feel Mobile is overall
> moving
> > in the right direction. In my experience, Mobile development has good
> > interpersonal harmony among participants, and everyone is hoping to
> convert
> > a portion of mobile app users to new contributors.
> >
> > Pine
> > On Aug 14, 2014 11:58 PM, "Gerard Meijssen" <[hidden email]>
> > wrote:
> >
> > > Hoi,
> > > I am getting so pissed off.
> > >
> > > Let us be realistic. The user experience sucks ... It sucks big time
> and
> > > even though the "community" is comfortable with it, it impedes the use
> by
> > > the people we do it all for. They are the READERS.. they are not the
> > > editors and the least this is done for are the people who are so
> > indignant
> > > because their experience changes.
> > >
> > > When you look at the last year, the biggest changes are driven by the
> > > development for mobiles. The projections make it plain this is where
> our
> > > customers will be. The existing Wikipedia with its monobook and what
> have
> > > you skin will not be seen, used or be relevant to them. Our traffic is
> > > transitioning to mobile. Editing starts to happen on mobile and if it
> is
> > > not clear to the "community" that future development will be in this
> > > direction they live under a rock or they are in denial.
> > >
> > > Have a look at a Commons page on a mobile.. It is beyond bad and beyond
> > > useful. With the Multimedia viewer it becomes useful. (NB there are
> > things
> > > in there that are brain dead but that is a different story)
> > >
> > > WAKE UP. Our world is changing. Trying to shame the WMF development in
> a
> > > different direction is counter productive, ill considered and even
> > > destructive. When you are the "community", and when this is new to
> you, I
> > > hope you will sit back for a moment and consider this.  When this does
> > not
> > > make a difference to you, there is always the right of departure. In my
> > > brutal opinion we have no option but to move towards a more mobile
> > centred
> > > appreciation. The alternative is stagnation and irrelevance. That does
> > not
> > > need to happen when we accept that the world changes around us.
> > > Thanks,
> > >      GerardM
> > >
> > >
> > > On 14 August 2014 17:28, Tim Davenport <[hidden email]> wrote:
> > >
> > > > Re: Erik Möller's remark: "In general, though, let's talk. The
> > > overarching
> > > > principle we're not
> > > > going to budge on is that this process is really not acceptable:
> > > >
> > > > 1) The UI changes
> > > > 2) A subset of users is upset and organizes a poll/vote
> > > > 3) The poll/vote closes with a request to undo said UI Change and a
> > > > request is filed
> > > > 4) WMF offers compromise or says no
> > > > 5) A local hack is used to undo said UI change
> > > >
> > > > That's no way to develop software, and that's no way to work
> > > together...."
> > > >
> > > > =========
> > > >
> > > > I could spend 10,000 words on this. I'll try to keep it
> (comparatively)
> > > > short.
> > > >
> > > >
> > > > The reason this dysfunctional situation develops, Erik, is because
> > there
> > > > are no steps A, B, C, D, E, F, and G preceding #1 on the list.
> > > >
> > > > As things currently stand, this is the way the software development
> > > process
> > > > at WMF seems to me to work:
> > > >
> > > > * Engineers collecting paychecks obviously need something to do.
> > > > * Someone comes up with a bright idea that sounds good on paper.
> > > > * Engineers decide to make that idea a reality and start work.
> > > > * Inadequately tested software, sometimes of dubious utility, is
> > > > unilaterally imposed on volunteers.
> > > > * If new software is problematic enough, volunteers revolt by any
> means
> > > > necessary.
> > > > * WMF forces changes down throat of volunteers by any means
> necessary.
> > > >
> > > > This is truly "no way to develop software" and "no way to work
> > together."
> > > >
> > > > -----
> > > >
> > > > Here is the way the process SHOULD begin:
> > > >
> > > > * WMF staffers, plural, identify by user names/IP addresses the
> 10,000
> > or
> > > > so very active volunteers across all projects and database them.
> > > >
> > > > * WMF staffers further divide this group into coherent "types":
> content
> > > > writers, gnome-type copy editors, structural adapters (template
> people,
> > > bot
> > > > operators, etc.), quality control workers (NPP, AfD), vandal
> fighters,
> > > > behavioral administrators (ArbCom, Ani, the various Admin pages), and
> > > drone
> > > > bees who do nothing but Facebook-style drama mongering. Multiple
> > > categories
> > > > may apply to single individuals and this list is not necessarily
> > > > exhaustive.
> > > >
> > > > * Once identified, WMF staffers frequently and regularly poll very
> > active
> > > > users in each category about WHAT THEY NEED. Different surveys for
> > > > different volunteer types.
> > > >
> > > > * Software development starts ONLY when a real need is identified.
> > > >
> > > > * Software should be introduced on En-WP, De-WP, or Commons ONLY when
> > it
> > > is
> > > > Alpha-grade, debugged and ready to roll. (Test things on the smaller
> > > Wikis
> > > > first).
> > > >
> > > > -----
> > > >
> > > > Moreover, there should be some polling mechanism to summarize and
> > analyze
> > > > what the 500 million or whatever readers worldwide feel that they
> like
> > > and
> > > > feel they are missing. "User experience" changes with primary impact
> on
> > > > readers rather than volunteers (such as MediaViewer) should be made
> > with
> > > > them in mind first and foremost; editing and structural tools should
> be
> > > > made to actually assist the active volunteers, not created on a whim.
> > > >
> > > > Sometimes the needs of the Readers and the needs of the Volunteers
> are
> > > > different, let us frankly say. In no case should WMF assume the views
> > and
> > > > criticism of the latter are insignificant or wrong simply because
> > > > 500,000,000 > 10,000.
> > > >
> > > > Remember this because according to the same logic: 10,000 > 240.
> > > >
> > > > -----
> > > >
> > > > We all agree that we need a bigger pool of very active volunteers.
> Most
> > > > readers are never going to be very active volunteers, nor do we want
> > them
> > > > to be, since we need specialized skill sets. Most people using the
> > > editing
> > > > software are only going to make one or a very few changes a year and
> > they
> > > > are never going to even "see" the backstage world of Wikipedia. That
> is
> > > > normal and fine.
> > > >
> > > > We do need expert contributors on esoteric topics and we need solid
> > > > contributors from the developing world and we need to replenish the
> > > people
> > > > doing copy editing and quality control work.
> > > >
> > > > We don't need tools that nobody asked for and nobody wants shoved
> down
> > > our
> > > > throats just because engineers needed something to do.
> > > >
> > > >
> > > >
> > > > 240 Paid Staff + 10,000 Serious Volunteers + 500,000,000 Readers and
> > > > occasional minor contributors
> > > >
> > > > Three groups with differing needs.
> > > >
> > > >
> > > > Tim Davenport /// "Carrite" on WP /// "Randy from Boise" on WPO
> > > > Corvallis, OR
> > > > _______________________________________________
> > > > Wikimedia-l mailing list, guidelines at:
> > > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > > [hidden email]
> > > > Unsubscribe:
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > > <mailto:[hidden email]?subject=unsubscribe>
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Dan Garry
On 15 August 2014 06:08, Todd Allen <[hidden email]> wrote:
>
> Developing for mobile is nice and should continue, but desktop is far from
> dead. I don't even try to edit from mobile; I want my real keyboard and
> monitor, not the crappy on screen one and 3" display.
>

This is a false dilemma. The WMF does not have any plans to stop developing
desktop features. On the contrary, the VisualEditor team recently changed
scope to be the Editing team in part so that the scope of their team also
included maintaining the wikitext editor on desktop.

Dan

--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Rich Farmbrough
There are 105 bugs open for Media Viewer.  To my mind that is not a product
that is ready to be delivered to 500,000,000 users, delivering  52.5
billion bugs!  (And that's just the ones we know about!)

But even if it was, the fact  that a project community has asked for it to
be opt-in should be respected by the developers.  The idea that  software
developers control the roll-out of their own software is "no way to develop
software"  User acceptance testing was invented, what, 50 or 60 years ago?


On 15 August 2014 14:45, Dan Garry <[hidden email]> wrote:

> On 15 August 2014 06:08, Todd Allen <[hidden email]> wrote:
> >
> > Developing for mobile is nice and should continue, but desktop is far
> from
> > dead. I don't even try to edit from mobile; I want my real keyboard and
> > monitor, not the crappy on screen one and 3" display.
> >
>
> This is a false dilemma. The WMF does not have any plans to stop developing
> desktop features. On the contrary, the VisualEditor team recently changed
> scope to be the Editing team in part so that the scope of their team also
> included maintaining the wikitext editor on desktop.
>
> Dan
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>



--
Landline (UK) 01780 757 250
Mobile (UK) 0798 1995 792
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Chad Horohoe
On Aug 17, 2014 6:49 AM, "Richard Farmbrough" <[hidden email]>
wrote:
>
> There are 105 bugs open for Media Viewer.  To my mind that is not a
product
> that is ready to be delivered to 500,000,000 users, delivering  52.5
> billion bugs!  (And that's just the ones we know about!)
>

MediaWiki itself has 4893 open bugs. Guess we need to start over so we can
write bug-free software.

Except that's not how it works, absolute bug counts are a pretty useless
metric.

-Chad
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Comet styles
yes but mediawiki is a software, not an "add-on" or as the kids say
these days, an "App" which is what Media Viewer is. Enforcing
something with more than a 100 bugs (and counting) is indeed not a
very super idea..Fix the bugs or atleast half of them and maybe then
try "enforcing them" (as WMF ignores community decisions)......

On 8/17/14, Chad Horohoe <[hidden email]> wrote:

> On Aug 17, 2014 6:49 AM, "Richard Farmbrough" <[hidden email]>
> wrote:
>>
>> There are 105 bugs open for Media Viewer.  To my mind that is not a
> product
>> that is ready to be delivered to 500,000,000 users, delivering  52.5
>> billion bugs!  (And that's just the ones we know about!)
>>
>
> MediaWiki itself has 4893 open bugs. Guess we need to start over so we can
> write bug-free software.
>
> Except that's not how it works, absolute bug counts are a pretty useless
> metric.
>
> -Chad
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>


--
Cometstyles

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Rich Farmbrough
And that is a common community complaint, games communities, social
communities, and content communities.

They all say "fix the bugs before working on new stuff."  Developers prefer
working on new stuff, managers prefer working on new stuff. Where's the
kudos from making things bug-free?  But that is what is needed.


On 17 August 2014 13:48, Comet styles <[hidden email]> wrote:

> yes but mediawiki is a software, not an "add-on" or as the kids say
> these days, an "App" which is what Media Viewer is. Enforcing
> something with more than a 100 bugs (and counting) is indeed not a
> very super idea..Fix the bugs or atleast half of them and maybe then
> try "enforcing them" (as WMF ignores community decisions)......
>
> On 8/17/14, Chad Horohoe <[hidden email]> wrote:
> > On Aug 17, 2014 6:49 AM, "Richard Farmbrough" <[hidden email]>
> > wrote:
> >>
> >> There are 105 bugs open for Media Viewer.  To my mind that is not a
> > product
> >> that is ready to be delivered to 500,000,000 users, delivering  52.5
> >> billion bugs!  (And that's just the ones we know about!)
> >>
> >
> > MediaWiki itself has 4893 open bugs. Guess we need to start over so we
> can
> > write bug-free software.
> >
> > Except that's not how it works, absolute bug counts are a pretty useless
> > metric.
> >
> > -Chad
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
>
>
> --
> Cometstyles
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>



--
Landline (UK) 01780 757 250
Mobile (UK) 0798 1995 792
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Pete Forsyth-2
I think it is also a problem to look at this in terms of "bugs." I don't
think you can retrofit good design into something that has a variety of
substantial problems, by merely "squashing bugs." You might say that is the
wiki way, but it is widely known that some tasks are better suited than
others to ad hoc collaborative processes.

In this case, we have a broad range of issues:
* does it let the reader know they can help improve the page or upload
another photo
* does it reflect copyright holders' licenses accurately and effectively
* does it adequately respect the privacy of the subjects of photos
* does it reflect a "look and feel" that we feel OK about and is consistent
with the rest of the software
etc. etc.

Fixing one "bug" may well lead to other bugs, or negatively impact those
already reported. What is needed, I believe, is a well-facilitated process
to identify the problems and the best solutions. This is not easy to do and
takes time. But I think the WMF has (not for lack of trying) managed to do
a very bad job of that with this software product, and with many software
products in the last few years. That does not mean it is impossible to do
it that way, only that those specific efforts were insufficient.

An example of a design process that DID work well, I believe, is the 2012
rewrite of the Terms of Use. The goals were clearly stated upfront, a
deadline was stated *and then moved* when it was determined that it was too
soon and good work was being done, the discussion was facilitated in a
highly useful way (noting things that are off topic, closing issues as they
are resolved, actively drawing in staff as needed, etc.)

-Pete
[[User:Peteforsyth]]


On Sun, Aug 17, 2014 at 4:46 PM, Richard Farmbrough <
[hidden email]> wrote:

> And that is a common community complaint, games communities, social
> communities, and content communities.
>
> They all say "fix the bugs before working on new stuff."  Developers prefer
> working on new stuff, managers prefer working on new stuff. Where's the
> kudos from making things bug-free?  But that is what is needed.
>
>
> On 17 August 2014 13:48, Comet styles <[hidden email]> wrote:
>
> > yes but mediawiki is a software, not an "add-on" or as the kids say
> > these days, an "App" which is what Media Viewer is. Enforcing
> > something with more than a 100 bugs (and counting) is indeed not a
> > very super idea..Fix the bugs or atleast half of them and maybe then
> > try "enforcing them" (as WMF ignores community decisions)......
> >
> > On 8/17/14, Chad Horohoe <[hidden email]> wrote:
> > > On Aug 17, 2014 6:49 AM, "Richard Farmbrough" <
> [hidden email]>
> > > wrote:
> > >>
> > >> There are 105 bugs open for Media Viewer.  To my mind that is not a
> > > product
> > >> that is ready to be delivered to 500,000,000 users, delivering  52.5
> > >> billion bugs!  (And that's just the ones we know about!)
> > >>
> > >
> > > MediaWiki itself has 4893 open bugs. Guess we need to start over so we
> > can
> > > write bug-free software.
> > >
> > > Except that's not how it works, absolute bug counts are a pretty
> useless
> > > metric.
> > >
> > > -Chad
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> >
> >
> > --
> > Cometstyles
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
>
>
>
> --
> Landline (UK) 01780 757 250
> Mobile (UK) 0798 1995 792
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Risker
Well, hold on here.


On 17 August 2014 19:55, Pete Forsyth <[hidden email]> wrote:

> I think it is also a problem to look at this in terms of "bugs." I don't
> think you can retrofit good design into something that has a variety of
> substantial problems, by merely "squashing bugs." You might say that is the
> wiki way, but it is widely known that some tasks are better suited than
> others to ad hoc collaborative processes.
>


Given the current use of bugzilla, which doesn't limit itself to bugs but
also feature requests and enhancements over the base functionality, calling
everything reported using bugzilla a "bug" is incorrect and inappropriate.


>
> In this case, we have a broad range of issues:
> * does it let the reader know they can help improve the page or upload
> another photo
>

The Commons/File pages don't do that, why would you expect this software to
do it?


> * does it reflect copyright holders' licenses accurately and effectively
>

Agree this is important.  Do you have any evidence that it is any less
accurate than the Commons/File pages?


> * does it adequately respect the privacy of the subjects of photos
>

The mere fact of the image being used on an article anywhere on a Wikimedia
project suggests that this problem is in the actual usage, not in the
software being used to display more information and detail in the image.
If you believe that this is a serious issue, then it should be addressed
where 100% of readers can see it, not in a subpage viewed only by the
limited number of readers who click on the image. It's not a Media Viewer
problem, it's an image usage problem.


> * does it reflect a "look and feel" that we feel OK about and is consistent
> with the rest of the software
> etc. etc.
>

What problems are you seeing here?  Spell it out, rather than making vague
suggestions that there is an issue.



>
> Fixing one "bug" may well lead to other bugs, or negatively impact those
> already reported. What is needed, I believe, is a well-facilitated process
> to identify the problems and the best solutions. This is not easy to do and
> takes time. But I think the WMF has (not for lack of trying) managed to do
> a very bad job of that with this software product, and with many software
> products in the last few years. That does not mean it is impossible to do
> it that way, only that those specific efforts were insufficient.
>


Why is this a Media Viewer issue?  This is a problem for all types of
software on all types of platforms, and is a challenge even for IT
departments hundreds of times the size of the WMF.  I cannot think of any
software I have used in the last 20 years that has not had "bugs" or
unsatisfactory UI elements or seems to miss a functionality I'd like to
have.  It is unreasonable to hold a comparatively very small organization
to a standard that can't even be met by IT giants.

Risker/Anne
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Pete Forsyth-2
On Sun, Aug 17, 2014 at 5:12 PM, Risker <[hidden email]> wrote:

> Well, hold on here.
>
>
> On 17 August 2014 19:55, Pete Forsyth <[hidden email]> wrote:
>
> > I think it is also a problem to look at this in terms of "bugs." I don't
> > think you can retrofit good design into something that has a variety of
> > substantial problems, by merely "squashing bugs." You might say that is
> the
> > wiki way, but it is widely known that some tasks are better suited than
> > others to ad hoc collaborative processes.
> >
>
>
> Given the current use of bugzilla, which doesn't limit itself to bugs but
> also feature requests and enhancements over the base functionality, calling
> everything reported using bugzilla a "bug" is incorrect and inappropriate.
>

While this is true, I have yet to see bugzilla used as a platform for a
design process for Media Viewer, and I don't think I would recommend it.
It's *possible* to use it as a platform for more than mere bugs, and it has
been done before; but I don't think tha'ts what's going on here, or should
go on here.


> > In this case, we have a broad range of issues:
> > * does it let the reader know they can help improve the page or upload
> > another photo
> >
>
> The Commons/File pages don't do that, why would you expect this software to
> do it?
>

The Commons/File page DOES do that, to the extent that readers have some
familiarity with MediaWiki software and how to find the "Edit" button. You
may not believe that is significant, but I encounter people on an almost
daily basis who are mystified by Wikipedia, but at least have a basic
understanding what the "edit" button does, or could allow them to do. It
may not be all readers or even a majority, but it is my very strong belief
-- rooted, perhaps not in rigorous scientific analysis, but in my very
active engagement with non-Wikipedias since 2006 -- that it's the pool of
people who tend to replenish our declining editor pool. A great many of the
100+ students who signed up for the 4 rounds of my online course on editing
Wikipedia, for instance, had accounts that were several years old, but only
had a dozen or so edits.

> * does it reflect copyright holders' licenses accurately and effectively
> >
>
> Agree this is important.  Do you have any evidence that it is any less
> accurate than the Commons/File pages?
>

That evidence is all over the various RFCs and wiki pages related to this,
and also in Bugzilla I believe, I'll leave it to you to track it down.

> * does it adequately respect the privacy of the subjects of photos
> >
>
> The mere fact of the image being used on an article anywhere on a Wikimedia
> project suggests that this problem is in the actual usage, not in the
> software being used to display more information and detail in the image.
> If you believe that this is a serious issue, then it should be addressed
> where 100% of readers can see it, not in a subpage viewed only by the
> limited number of readers who click on the image. It's not a Media Viewer
> problem, it's an image usage problem.
>

This point has a lot of nuance in it, and I'm happy to discuss it, but not
here and now. If you want to dig into it, I suggest this as a venue:
https://commons.wikimedia.org/wiki/Template_talk:Consent -- if you leave a
note there, please {{ping|Peteforsyth}} so I can find it.


> > * does it reflect a "look and feel" that we feel OK about and is
> consistent
> > with the rest of the software
> > etc. etc.
> >
>
> What problems are you seeing here?  Spell it out, rather than making vague
> suggestions that there is an issue.
>

I don't personally have a big issue with this one; but it's something
others have brought up. I'm trying to capture the breadth of concerns about
the software here, rather than (as WMF staff keep inaccurately accusing me
and many of my colleagues of doing) saying merely "I DON'T LIKE IT."

>
>
>
> >
> > Fixing one "bug" may well lead to other bugs, or negatively impact those
> > already reported. What is needed, I believe, is a well-facilitated
> process
> > to identify the problems and the best solutions. This is not easy to do
> and
> > takes time. But I think the WMF has (not for lack of trying) managed to
> do
> > a very bad job of that with this software product, and with many software
> > products in the last few years. That does not mean it is impossible to do
> > it that way, only that those specific efforts were insufficient.
> >
>
>
> Why is this a Media Viewer issue?  This is a problem for all types of
> software on all types of platforms, and is a challenge even for IT
> departments hundreds of times the size of the WMF.  I cannot think of any
> software I have used in the last 20 years that has not had "bugs" or
> unsatisfactory UI elements or seems to miss a functionality I'd like to
> have.  It is unreasonable to hold a comparatively very small organization
> to a standard that can't even be met by IT giants.
>

It is absolutely a problem for all types of software on all types of
platforms. It is a Media Viewer issue because the design and deployment was
executed so badly that it caused a significant backlash on 3 major projects.

And again -- the WMF has done this well in some cases, there's no need to
look at mega corporations to find good models. All I am suggesting is that
the WMF do a better job of learning from its own successes.

Pete
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Risker
On 17 August 2014 20:25, Pete Forsyth <[hidden email]> wrote:

> On Sun, Aug 17, 2014 at 5:12 PM, Risker <[hidden email]> wrote:
>
> > Well, hold on here.
> >
> >
> > On 17 August 2014 19:55, Pete Forsyth <[hidden email]> wrote:
> >
> > > I think it is also a problem to look at this in terms of "bugs." I
> don't
> > > think you can retrofit good design into something that has a variety of
> > > substantial problems, by merely "squashing bugs." You might say that is
> > the
> > > wiki way, but it is widely known that some tasks are better suited than
> > > others to ad hoc collaborative processes.
> > >
> >
> >
> > Given the current use of bugzilla, which doesn't limit itself to bugs but
> > also feature requests and enhancements over the base functionality,
> calling
> > everything reported using bugzilla a "bug" is incorrect and
> inappropriate.
> >
>
> While this is true, I have yet to see bugzilla used as a platform for a
> design process for Media Viewer, and I don't think I would recommend it.
> It's *possible* to use it as a platform for more than mere bugs, and it has
> been done before; but I don't think tha'ts what's going on here, or should
> go on here.
>
>
Perhaps you should get to know a bit more about bugzilla and its current
usage; of the 104 current reports on Multimedia Viewer, 16 are enhancements
and several others that are currently listed as "bugs" of varying
importance/urgency are "features" that don't appear to exist in the
"standard" format for viewing images or are so badly designed in the File
pages that they're almost impossible to call acceptable in that format,
either.

Someone who is better able to describe the developer functions could better
describe the planned changes from the use of Bugzilla to Phabricator, which
is a more flexible platform that (I understand) is intended to consolidate
several different design/development/improvement/bug reporting platforms
currently in use.  But right now, bugzilla is at least in some cases used
as a platform for the design process of just about everything to do with
MediaWiki, its extensions, and all the other platforms that are in
use/developed by WMF.

Every single type of software used on Wikimedia project sites, as well as
software for other features provided by the WMF, has bugzilla reports.
There are thousands for MediaWiki, the core software of the project.  We
haven't thrown in the towel on it just because it's got lots of bugzilla
reports.



>
> > > In this case, we have a broad range of issues:
> > > * does it let the reader know they can help improve the page or upload
> > > another photo
> > >
> >
> > The Commons/File pages don't do that, why would you expect this software
> to
> > do it?
> >
>
> The Commons/File page DOES do that, to the extent that readers have some
> familiarity with MediaWiki software and how to find the "Edit" button. You
> may not believe that is significant, but I encounter people on an almost
> daily basis who are mystified by Wikipedia, but at least have a basic
> understanding what the "edit" button does, or could allow them to do. It
> may not be all readers or even a majority, but it is my very strong belief
> -- rooted, perhaps not in rigorous scientific analysis, but in my very
> active engagement with non-Wikipedias since 2006 -- that it's the pool of
> people who tend to replenish our declining editor pool. A great many of the
> 100+ students who signed up for the 4 rounds of my online course on editing
> Wikipedia, for instance, had accounts that were several years old, but only
> had a dozen or so edits.
>

I'm sorry.  How, exactly, do you envision a new editor or reader improving
file pages? There's not very much that can be edited there that isn't going
to cause more problems than it solves. Should they modify the author?
Change the license?   Add (potentially non-existent) categories?  When the
chances of reversion are nearly 100%, it's not necessarily a net positive
to make a big deal about the existence of an "edit" button.  Media pages
are not really comparable to (written) content pages. I'd rank file pages
as possibly the worst place to suggest that new editors just jump in, with
the possible exception of templates.

<snip>

> * does it adequately respect the privacy of the subjects of photos
> >
>
> The mere fact of the image being used on an article anywhere on a
Wikimedia
> project suggests that this problem is in the actual usage, not in the
> software being used to display more information and detail in the image.
> If you believe that this is a serious issue, then it should be addressed
> where 100% of readers can see it, not in a subpage viewed only by the
> limited number of readers who click on the image. It's not a Media Viewer
> problem, it's an image usage problem.
>

This point has a lot of nuance in it, and I'm happy to discuss it, but not
> here and now. If you want to dig into it, I suggest this as a venue:
> https://commons.wikimedia.org/wiki/Template_talk:Consent -- if you leave a
> note there, please {{ping|Peteforsyth}} so I can find it.
>
>
I am at a loss as to why a template on Commons has anything to do with the
privacy of subjects of photos.  And yes, I read that entire page over
twice. Templates are simply a manner in which to facilitate the level of
adherence to certain policies (and in some cases legal requirements);
they're not the place to discuss over-arching philosophy.


>
> > > * does it reflect a "look and feel" that we feel OK about and is
> > consistent
> > > with the rest of the software
> > > etc. etc.
> > >
> >
> > What problems are you seeing here?  Spell it out, rather than making
> vague
> > suggestions that there is an issue.
> >
>
> I don't personally have a big issue with this one; but it's something
> others have brought up. I'm trying to capture the breadth of concerns about
> the software here, rather than (as WMF staff keep inaccurately accusing me
> and many of my colleagues of doing) saying merely "I DON'T LIKE IT."
>

Well, if you don't have a problem with it, why are you including it in your
list of problems? This is exactly how what might very well be a problem for
a very small number of users gets inflated to be considered a big issue for
a large number of users.  For the record: I don't care one way or the
other; I can use file pages, I can use MMV, and since I don't do a lot of
file work either is fine for me. I didn't opt in before hand, but I haven't
opted out since it went live.  It would be helpful for others to give
serious thought to why they've decided to opt in (before) or opt out (after
default deployment) and then report this so that realistic data can be
collected.  I'm going to be honest, I've seen a lot of "I don't like it",
but I've also seen some good reasons, for personal decisions either way.
I've not seen a lot of good arguments for disabling it for readers, though,
especially as it exists today.


>
> >
> >
> >
> > >
> > > Fixing one "bug" may well lead to other bugs, or negatively impact
> those
> > > already reported. What is needed, I believe, is a well-facilitated
> > process
> > > to identify the problems and the best solutions. This is not easy to do
> > and
> > > takes time. But I think the WMF has (not for lack of trying) managed to
> > do
> > > a very bad job of that with this software product, and with many
> software
> > > products in the last few years. That does not mean it is impossible to
> do
> > > it that way, only that those specific efforts were insufficient.
> > >
> >
> >
> > Why is this a Media Viewer issue?  This is a problem for all types of
> > software on all types of platforms, and is a challenge even for IT
> > departments hundreds of times the size of the WMF.  I cannot think of any
> > software I have used in the last 20 years that has not had "bugs" or
> > unsatisfactory UI elements or seems to miss a functionality I'd like to
> > have.  It is unreasonable to hold a comparatively very small organization
> > to a standard that can't even be met by IT giants.
> >
>
> It is absolutely a problem for all types of software on all types of
> platforms. It is a Media Viewer issue because the design and deployment was
> executed so badly that it caused a significant backlash on 3 major
> projects.
>
> And again -- the WMF has done this well in some cases, there's no need to
> look at mega corporations to find good models. All I am suggesting is that
> the WMF do a better job of learning from its own successes.
>
>
Your comparison in your initial post was to a policy discussion on the
Terms of Use, which you felt went well.  And yet, this was a discussion on
a single site, Meta, where very few Wikimedians participate; there was no
particular outreach to projects except to meet the legal obligation of
making reasonable efforts to notify users of a change in the TOU. For MMV,
we have, at minimum:


   - Beta features option in the user preferences for all users on all
   projects.  Unfortunately, an administrator unilaterally removed this
   preference tab on dewiki, thus withdrawing the opportunity for any users on
   that project to opt in and test and comment on this and other software
   throughout the stages of development. I understand this has now been
   restored, and look forward to seeing comments on many software changes from
   our colleagues on that project. Or not - it's their choice.
   - Posts on Village Pumps and other appropriate locations on hundreds of
   project sites
   - Information provided to site-specific information dissemination
   functions (e.g., Signpost on 14 May 2014 and earlier)
   - Active attempts to seek out user opinions through questionnaires.
   (Yes, I know there was some perception of bias in the wording of some
   questions. Nonetheless, this is an additional opportunity for gathering
   information that was not used for the TOU.)

In other words, you thought a discussion on a single site went well, but
one that took place across hundreds of sites didn't do enough to inform
people and seek feedback.  Do you see why I am perceiving a bias on your
part?

Commons has a very different use case for information about files and media
than any other project site in the Wikimedia family, and it seems to me
that the WMF listened when that community pointed out their differing
needs; again, despite lots of advance notice it seems that not a lot of
Commons users communicated these concerns before deployment.  Both Enwiki
and Dewiki have had a troubled relationship with the WMF (and particularly
the Engineering & Product departments) in recent history. In the case of
enwiki, though, an RFC on this specific topic still could only draw 64
editors supporting opt-in for MMV (as opposed to opt-out or default
status).  Dewiki had stronger support for moving away from default status,
although this was the project that had little opportunity to test in
advance because of the removal of the opt-in option in advance of its
deployment there.  That was a shame, because our dewiki colleagues have
often provided very useful comments and recommendations for improvement of
other software in development.

In other words....everyone has something to learn here, but perhaps the
most important and valuable point is that changes are going to keep
happening across these sites - in fact, they're made every week, although
not always as major as this - and there is a huge need from all sides for
users to participate and identify concerns while software is being
developed so that problems that aren't necessarily obvious to developers
will be flushed out before largescale deployments.  At the same time,
product managers and developers need to work with users to identify the
difference between minor concerns and concerns that should be considered
"blockers" as software is being developed/improved/modified/etc.


Risker/Anne
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

David Gerard-2
In reply to this post by Rich Farmbrough
On 17 August 2014 05:49, Richard Farmbrough <[hidden email]> wrote:

> There are 105 bugs open for Media Viewer.  To my mind that is not a product
> that is ready to be delivered to 500,000,000 users, delivering  52.5
> billion bugs!  (And that's just the ones we know about!)



Mere open bug count is not in any way a useful measure of software
quality. It really, really doesn't work like that.


- d.

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Pete Forsyth-2
In reply to this post by Risker
Risker, some replies below:

On Sun, Aug 17, 2014 at 7:59 PM, Risker <[hidden email]> wrote:

> <snip>
> Perhaps you should get to know a bit more about bugzilla and its current
> usage;
>
<snip>

This topic is getting far afield. I have a reasonably good understanding of
how bugzilla works, and have reported and commented on a pretty wide
variety of bugs. I generally agree with everything you have to say about
it. My point really had nothing to do with platforms, though -- it was
about the way the organization and the movement approaches design. There
might be a worthwhile discussion to be had about platform use, but I don't
think it belongs in this thread, and I'm not sure I'd bother to participate
-- there are many people better qualified and more motivated than me to dig
into this stuff.

I'm sorry.  How, exactly, do you envision a new editor or reader improving
> file pages? There's not very much that can be edited there that isn't going
> to cause more problems than it solves.
> <snip>


I am frankly astonished to see you say this. I don't have to envision
anything -- I watch people improve file pages on a daily basis, in much
more straightforward ways than the examples you chose. The single most
obvious thing is to expand the "Description" field, which often only has a
few words -- but there are all kinds of things people can and do improve.
And "new editor or reader" -- that may be your requirement, but it's not
mine. Paths from "newbie" to "experienced" involve many steps, and I don't
see any reason why the *first* step should be so heavily emphasized. I
don't think "newness" is the end-all-be-all. If somebody has been dabbling
on English Wikipedia for a few years, and comes across an image that they
know something about, or have the skills to improve and re-upload, etc.,
that may be an important moment where they start to realize that English
Wikipedia is part of a broader multilingual community. But will that moment
occur if they only ever experience media through the Media Viewer? I do not
know the answer to that question for certain, but I have a pretty strong
hunch.

I am at a loss as to why a template on Commons has anything to do with the
> privacy of subjects of photos.


I'm with you. And if the MV team had taken this view, they might have
skipped basing the way that personality rights are communicated to readers
on one template that is, so far, inadequate to the task of helping
uploaders comply with [[COM:IDENT]]. But they didn't skip it -- they
checked "personality rights" off the list by making the MV include this
template.

Understandable, if you're trying to hit a looming deadline and scrambling
to get a lot of stuff done. But in the end, totally inadequate. The way we
handle personality rights is a matter of vital concern to the future of
Wikipedia -- this has, as you know, been the topic of many discussions on
the Gender Gap email list and elsewhere.

Well, if you don't have a problem with it, why are you including it in your
> list of problems?


The list of problems is so huge, Risker, that I hardly think it matters
what specifics I do or don't include. This is software that is out of step
with what the Wikimedia movement is trying to accomplish, pure and simple.
If you disagree, fine. We'll see how it plays out.


> <snip>
> In other words, you thought a discussion on a single site went well, but
> one that took place across hundreds of sites didn't do enough to inform
> people and seek feedback.


Actually, no -- I think the efforts at notification were reasonably good.
The bigger problem I see is not so much with the notification, but the way
the design process was conducted. To put it simply, the biggest issue is
that the team working on this software has a listening problem. It's one
I'm familiar with because I've experienced it in various interactions with
the broader WMF over a period of years. There is bias in the assumptions
the team brings to the project, and they "hear" the input that comes from
volunteers through the filter of that bias. One of the results is that in
many cases, they attempt to reflect back what was said to them, but end up
saying something completely different.

And when you're not doing a good job of listening, one of the overall
results is that you have a poor ability to predict how things will go. Lila
Tretikov asked on her user talk page last week:

"It is a bit strange to see this being such a big deal given that the
feature has been in Beta for nearly a year, was rolled out almost
everywhere else in April with no issues, and has been on the de site since
early June. So clearly it has not broken things. Why did it get so "hot"
*after* two month of being in production, without reader complaints? Just
wondering..."

As I stated in my response, although the WMF failed to predict that this
would be a hot issue, I predicted it clearly in February, and so did
another longtime community member. (If anybody wants to see that other
piece, let me know -- I now have permission to share it, actually an IRC
log, not an email.)
https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov&diff=9512960&oldid=9512915

<snip>

> In other words....everyone has something to learn here, but perhaps the
> most important and valuable point is that changes are going to keep
> happening across these sites - in fact, they're made every week, although
> not always as major as this - and there is a huge need from all sides for
> users to participate and identify concerns while software is being
> developed so that problems that aren't necessarily obvious to developers
> will be flushed out before largescale deployments.  At the same time,
> product managers and developers need to work with users to identify the
> difference between minor concerns and concerns that should be considered
> "blockers" as software is being developed/improved/modified/etc.


I agree 100%.

Pete
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

svetlana
In reply to this post by Risker
Hi,

On Mon, 18 Aug 2014, at 10:12, Risker wrote:

> Well, hold on here.
>
>
> On 17 August 2014 19:55, Pete Forsyth <[hidden email]> wrote:
>
> > I think it is also a problem to look at this in terms of "bugs." I don't
> > think you can retrofit good design into something that has a variety of
> > substantial problems, by merely "squashing bugs." You might say that is the
> > wiki way, but it is widely known that some tasks are better suited than
> > others to ad hoc collaborative processes.
> >
>
>
> Given the current use of bugzilla, which doesn't limit itself to bugs but
> also feature requests and enhancements over the base functionality, calling
> everything reported using bugzilla a "bug" is incorrect and inappropriate.
>
>
> >
> > In this case, we have a broad range of issues:
> > * does it let the reader know they can help improve the page or upload
> > another photo
> >
>
> The Commons/File pages don't do that, why would you expect this software to
> do it?

It does. There is an Edit button at the top, and an Upload button at the left.

>
>
> > * does it reflect copyright holders' licenses accurately and effectively
> >
>
> Agree this is important.  Do you have any evidence that it is any less
> accurate than the Commons/File pages?
>
>
> > * does it adequately respect the privacy of the subjects of photos
> >
>
> The mere fact of the image being used on an article anywhere on a Wikimedia
> project suggests that this problem is in the actual usage, not in the
> software being used to display more information and detail in the image.
> If you believe that this is a serious issue, then it should be addressed
> where 100% of readers can see it, not in a subpage viewed only by the
> limited number of readers who click on the image. It's not a Media Viewer
> problem, it's an image usage problem.


Showing description is important for privacy of subject of photo in some cases. I.e. if I kill a cat for a movie and someone takes a picture, I should be able to tell readers that I'm doing this for a movie. The long description usually does so, if needed. Otherwise the readers might perceive that doing this is my usual activity.

This is probably not the original issue in mind of the first folk who mentioned privacy two paragraphs up there, but that's the first thing I can think of.

Another thing is slideshows. "The Big Pictures" website lets people browse pictures with long descriptions. We have galleries, and MV's left/right arrows. Why not make something in the middle, with both a long description/caption, and these left/right arrows?

>
>
> > * does it reflect a "look and feel" that we feel OK about and is consistent
> > with the rest of the software
> > etc. etc.
> >
>
> What problems are you seeing here?  Spell it out, rather than making vague
> suggestions that there is an issue.

MV is inconsistent, because other pages (history, talk) still force a page reload, for instance, and returning from them back to an article isn't as easy as one 'X' button.

>
>
>
> >
> > Fixing one "bug" may well lead to other bugs, or negatively impact those
> > already reported. What is needed, I believe, is a well-facilitated process
> > to identify the problems and the best solutions. This is not easy to do and
> > takes time. But I think the WMF has (not for lack of trying) managed to do
> > a very bad job of that with this software product, and with many software
> > products in the last few years. That does not mean it is impossible to do
> > it that way, only that those specific efforts were insufficient.
> >
>
>
> Why is this a Media Viewer issue?  This is a problem for all types of
> software on all types of platforms, and is a challenge even for IT
> departments hundreds of times the size of the WMF.  I cannot think of any
> software I have used in the last 20 years that has not had "bugs" or
> unsatisfactory UI elements or seems to miss a functionality I'd like to
> have.  It is unreasonable to hold a comparatively very small organization
> to a standard that can't even be met by IT giants.
>
> Risker/Anne

No comment on this one.

svetlana

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

svetlana
In reply to this post by Tim Davenport
Hi,

On Mon, 18 Aug 2014, at 10:12, Risker wrote:

> Well, hold on here.
>
>
> On 17 August 2014 19:55, Pete Forsyth <[hidden email]> wrote:
>
> > I think it is also a problem to look at this in terms of "bugs." I don't
> > think you can retrofit good design into something that has a variety of
> > substantial problems, by merely "squashing bugs." You might say that is the
> > wiki way, but it is widely known that some tasks are better suited than
> > others to ad hoc collaborative processes.
> >
>
>
> Given the current use of bugzilla, which doesn't limit itself to bugs but
> also feature requests and enhancements over the base functionality, calling
> everything reported using bugzilla a "bug" is incorrect and inappropriate.
>
>
> >
> > In this case, we have a broad range of issues:
> > * does it let the reader know they can help improve the page or upload
> > another photo
> >
>
> The Commons/File pages don't do that, why would you expect this software to
> do it?

It does. There is an Edit button at the top, and an Upload button at the left.

>
>
> > * does it reflect copyright holders' licenses accurately and effectively
> >
>
> Agree this is important.  Do you have any evidence that it is any less
> accurate than the Commons/File pages?
>
>
> > * does it adequately respect the privacy of the subjects of photos
> >
>
> The mere fact of the image being used on an article anywhere on a Wikimedia
> project suggests that this problem is in the actual usage, not in the
> software being used to display more information and detail in the image.
> If you believe that this is a serious issue, then it should be addressed
> where 100% of readers can see it, not in a subpage viewed only by the
> limited number of readers who click on the image. It's not a Media Viewer
> problem, it's an image usage problem.


Showing description is important for privacy of subject of photo in some cases. I.e. if I kill a cat for a movie and someone takes a picture, I should be able to tell readers that I'm doing this for a movie. The long description usually does so, if needed. Otherwise the readers might perceive that doing this is my usual activity.

This is probably not the original issue in mind of the first folk who mentioned privacy two paragraphs up there, but that's the first thing I can think of.

Another thing is slideshows. "The Big Pictures" website lets people browse pictures with long descriptions. We have galleries, and MV's left/right arrows. Why not make something in the middle, with both a long description/caption, and these left/right arrows?

>
>
> > * does it reflect a "look and feel" that we feel OK about and is consistent
> > with the rest of the software
> > etc. etc.
> >
>
> What problems are you seeing here?  Spell it out, rather than making vague
> suggestions that there is an issue.

MV is inconsistent, because other pages (history, talk) still force a page reload, for instance, and returning from them back to an article isn't as easy as one 'X' button.

>
>
>
> >
> > Fixing one "bug" may well lead to other bugs, or negatively impact those
> > already reported. What is needed, I believe, is a well-facilitated process
> > to identify the problems and the best solutions. This is not easy to do and
> > takes time. But I think the WMF has (not for lack of trying) managed to do
> > a very bad job of that with this software product, and with many software
> > products in the last few years. That does not mean it is impossible to do
> > it that way, only that those specific efforts were insufficient.
> >
>
>
> Why is this a Media Viewer issue?  This is a problem for all types of
> software on all types of platforms, and is a challenge even for IT
> departments hundreds of times the size of the WMF.  I cannot think of any
> software I have used in the last 20 years that has not had "bugs" or
> unsatisfactory UI elements or seems to miss a functionality I'd like to
> have.  It is unreasonable to hold a comparatively very small organization
> to a standard that can't even be met by IT giants.
>
> Risker/Anne

No comment on this one.

svetlana

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Risker
In reply to this post by Pete Forsyth-2
On 18 August 2014 03:53, Pete Forsyth <[hidden email]> wrote:

> Risker, some replies below:
>
> <snip>


 As I stated in my response, although the WMF failed to predict that this
would be a hot issue, I predicted it clearly in February, and so did
another longtime community member. (If anybody wants to see that other
piece, let me know -- I now have permission to share it, actually an IRC
log, not an email.)
https://meta.wikimedia.org/w/index.php?title=User_talk:
LilaTretikov&diff=9512960&oldid=9512915

(and the reference link:  https://www.mediawiki.org/w/index.php?diff=907392
)

Wow, Pete.  You predict something will be rejected by the community, and
identify a list of concerns.  Several months later, you apply the code that
applies a community "rejection".  This brings the term "self-fulfilling
prophecy" to a whole new level.  Just wow.

Risker/Anne
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Superprotect user right, Coming to a wiki near you

Rich Farmbrough
Lets straighten a few things out

1. Of course I don't think that bug counting is an accurate metric - and we
are all aware that Bugzilla contains other "items".  Nonetheless to pretend
that everything is rosy with MV is facile.

2. Specifically it appears that MV breaks CC-BY-SA-3.0.  Details on
Bugzilla.

3. But this is not really about MV.  It is about working with the
community.  The mission statement for the Foundation says "encourage and
empower" not "command and control".  There are good reasons for this, which
have been touched on in various places.

4. A culture change is needed, and there is little point in debating
specifics (except to add them to a list of what not to do) unless the
Foundation accepts that this needs to happen.

5. Moreover engaging in personalities within the community do not move
things forward, indeed they devalue the overall debate.


On 18 August 2014 13:55, Risker <[hidden email]> wrote:

> On 18 August 2014 03:53, Pete Forsyth <[hidden email]> wrote:
>
> > Risker, some replies below:
> >
> > <snip>
>
>
>  As I stated in my response, although the WMF failed to predict that this
> would be a hot issue, I predicted it clearly in February, and so did
> another longtime community member. (If anybody wants to see that other
> piece, let me know -- I now have permission to share it, actually an IRC
> log, not an email.)
> https://meta.wikimedia.org/w/index.php?title=User_talk:
> LilaTretikov&diff=9512960&oldid=9512915
>
> (and the reference link:
> https://www.mediawiki.org/w/index.php?diff=907392
> )
>
> Wow, Pete.  You predict something will be rejected by the community, and
> identify a list of concerns.  Several months later, you apply the code that
> applies a community "rejection".  This brings the term "self-fulfilling
> prophecy" to a whole new level.  Just wow.
>
> Risker/Anne
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>



--
Landline (UK) 01780 757 250
Mobile (UK) 0798 1995 792
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
12