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
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 shoehutch@gmail.com 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:
- The UI changes
- A subset of users is upset and organizes a poll/vote
- 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 Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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" gerard.meijssen@gmail.com 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 shoehutch@gmail.com 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:
- The UI changes
- A subset of users is upset and organizes a poll/vote
- 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 Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 wiki.pine@gmail.com 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" gerard.meijssen@gmail.com 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 shoehutch@gmail.com 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:
- The UI changes
- A subset of users is upset and organizes a poll/vote
- 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 Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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" gerard.meijssen@gmail.com 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 wiki.pine@gmail.com 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" gerard.meijssen@gmail.com 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 shoehutch@gmail.com 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:
- The UI changes
- A subset of users is upset and organizes a poll/vote
- 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 Wikimedia-l@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 15 August 2014 06:08, Todd Allen toddmallen@gmail.com 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
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 dgarry@wikimedia.org wrote:
On 15 August 2014 06:08, Todd Allen toddmallen@gmail.com 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 Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Aug 17, 2014 6:49 AM, "Richard Farmbrough" richard@farmbrough.co.uk 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
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 chorohoe@wikimedia.org wrote:
On Aug 17, 2014 6:49 AM, "Richard Farmbrough" richard@farmbrough.co.uk 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 Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 cometstyles@gmail.com 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 chorohoe@wikimedia.org wrote:
On Aug 17, 2014 6:49 AM, "Richard Farmbrough" richard@farmbrough.co.uk 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 Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Cometstyles
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 < richard@farmbrough.co.uk> 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 cometstyles@gmail.com 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 chorohoe@wikimedia.org wrote:
On Aug 17, 2014 6:49 AM, "Richard Farmbrough" <
richard@farmbrough.co.uk>
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 Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Cometstyles
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?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 Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Well, hold on here.
On 17 August 2014 19:55, Pete Forsyth peteforsyth@gmail.com 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
On Sun, Aug 17, 2014 at 5:12 PM, Risker risker.wp@gmail.com wrote:
Well, hold on here.
On 17 August 2014 19:55, Pete Forsyth peteforsyth@gmail.com 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
On 17 August 2014 20:25, Pete Forsyth peteforsyth@gmail.com wrote:
On Sun, Aug 17, 2014 at 5:12 PM, Risker risker.wp@gmail.com wrote:
Well, hold on here.
On 17 August 2014 19:55, Pete Forsyth peteforsyth@gmail.com 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
Risker, some replies below:
On Sun, Aug 17, 2014 at 7:59 PM, Risker risker.wp@gmail.com 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...
<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
On 18 August 2014 03:53, Pete Forsyth peteforsyth@gmail.com 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
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 risker.wp@gmail.com wrote:
On 18 August 2014 03:53, Pete Forsyth peteforsyth@gmail.com 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 Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I'm approaching this thread with some trepidation, but would someone mind telling me more about this - or pointing to where this issue is already documented? (I have no idea how to navigate Bugzilla ;) )
- Specifically it appears that MV breaks CC-BY-SA-3.0. Details on
Bugzilla.
Regards,
Chris
Bugzilla is at: https://bugzilla.wikimedia.org/
and you must create a login, as Bugzilla is not (so far as I know) part of SUL.
--Joe
On Mon, Aug 18, 2014 at 11:37 AM, Chris Keating chriskeatingwiki@gmail.com wrote:
I'm approaching this thread with some trepidation, but would someone mind telling me more about this - or pointing to where this issue is already documented? (I have no idea how to navigate Bugzilla ;) )
- Specifically it appears that MV breaks CC-BY-SA-3.0. Details on
Bugzilla.
Regards,
Chris _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hi,
On Mon, 18 Aug 2014, at 10:12, Risker wrote:
Well, hold on here.
On 17 August 2014 19:55, Pete Forsyth peteforsyth@gmail.com 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
On 17 August 2014 05:49, Richard Farmbrough richard@farmbrough.co.uk 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@lists.wikimedia.org