Hi folks,
This is a response to Martin's note here: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
.. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward.
I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it.
I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page.
Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a "better hack" to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint.
Our processes clearly need to be improved to avoid these situations in the future. We recognize that simply rejecting a community request rather than resolving a conflict together is not the right answer. We’ve been listening to feedback, and we’ve come to the following conclusions:
- We intend to undertake a review of our present processes immediately and propose a new approach that allows for feedback at more critical and relevant junctures in the next 90 days. This will be a transparent process that includes your voices.
- As the WMF, we need to improve the process for managing changes that impact all users. That includes the MediaWiki: namespace. For WMF to fulfill its role of leading consistent improvements to the user experience across Wikimedia projects, we need to be able to review code and manage deployments. This can be done in partnership with trusted volunteers, but WMF needs to be able to make an ultimate determination after receiving community feedback regarding production changes that impact all users.
- We are prepared to unprotect MediaWiki:Common.js on German Wikipedia and enter constructive, open-ended conversations about the way forward, provided we can mutually agree to do so on the basis of the current consistent configuration -- for now. We would like to request a moratorium on any attempts to disable the feature during this conflict resolution process. The goal would be to make a final, cross-wiki determination regarding this specific feature, in partnership with the community, within at most 90 days.
With regard to the German Wikipedia situation, we’d like to know if stewards want to at all be involved in this process: In a situation like this, it can be helpful to have a third party support the conversation. Stewards are accountable to "valid community consensus within the bounds of the Foundation's goals" [3], which seems to be precisely the intersection of concerns at issue here. We would like to suggest an IRC meeting with stewards ASAP to talk about the specific question of stewards’ involvement, if any. If stewards prefer not to be involved, we understand, but it's probably a good idea to have a sync-up conversation regardless.
I hope we can move forward in good faith from here, and find better ways to work together. As Lila has expressed, we believe there is a need for a clear understanding of our role. It is as follows:
Managing software development, site configuration and deployment is a core WMF responsibility. The community leads in the development of content; the Wikimedia Foundation leads in the development of technology.
Because these processes are deeply interdependent, we need to develop better protocols for timely feedback and resolution of disagreements. At the same time Lila’s and the Board’s statements make it very clear that the WMF will not accept RfCs or votes as the sole determining factor in global software deployments.
This means that technology and UX changes should not be decided by vote or poll and then disabled at-will: where we disagree, we need to talk to each other (and yes, that means a more judicious application of RESOLVED WONTFIX on our end, as well!). We need to ensure a process where the community voice is heard earlier at critical junctions in the product development. All of this is consistent with the principle of "shared power" articulated in the Guiding Principles [4] approved by the Board of Trustees.
At the same time, as noted above and earlier, the superprotection feature should be replaced with a better mechanism for code review and deployment in the MediaWiki: namespace. This is discussed in [5] and ideas and suggestions are welcome. Let’s be upfront about control structures for production changes to avoid misunderstandings and ambiguity in the future.
We are exploring options on how to improve dispute resolution mechanisms -- whether it’s e.g. a standing working group or a better protocol for responding to RfCs and engaging in discussions. We've started a brainstorming page, here, which we hope will usefully inform the process of conflict resolution regarding German Wikipedia, as well, so we can arrive at a more concrete conflict resolution process soon. Your thoughts/suggestions are welcome, so we can (in NPOV style) look at different possibilities (e.g. workgroups, committees, votes, surveys) that have been discussed in the past: https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
We’re absolutely not saying that WMF simply wants to be able to enforce its decisions: we completely understand there need to be mechanisms for the community to influence decisions and outcomes at all stages of the development and release of software. We need to arrive at this process together.
Again, we are sorry that this escalation occurred - and we hope we can move forward constructively from here.
Sincerely,
Erik
[1] https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbild...
[2] https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&am...
[3] https://meta.wikimedia.org/wiki/Stewards_policy
[4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shar...
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
Thank you, Erik, for your clarifications and understanding. Personally, I hope that most anger will calm down now although not everyone will agree with everything that was said or done (e.g. ignoring RfCs under some conditions, using superprotect instead of counting on local procedures to stop wheel warring) and we all can concentrate again on “working together to make Wikimedia projects are more welcome place for readers, authors, and anyone”. As this can only be done with mutual discussions, I'm looking forward to the intensified inclusion of the communities for future software developents as announced. Whether stewards can help here, I cannot tell, but I would abstain myself from getting involved for obvious reasons.
Cheers, Martin
2014-08-19 21:12 GMT+02:00 Erik Moeller erik@wikimedia.org:
Hi folks,
This is a response to Martin's note here: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
.. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward.
I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it.
I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page.
Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a "better hack" to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint.
Our processes clearly need to be improved to avoid these situations in the future. We recognize that simply rejecting a community request rather than resolving a conflict together is not the right answer. We’ve been listening to feedback, and we’ve come to the following conclusions:
- We intend to undertake a review of our present processes immediately
and propose a new approach that allows for feedback at more critical and relevant junctures in the next 90 days. This will be a transparent process that includes your voices.
- As the WMF, we need to improve the process for managing changes that
impact all users. That includes the MediaWiki: namespace. For WMF to fulfill its role of leading consistent improvements to the user experience across Wikimedia projects, we need to be able to review code and manage deployments. This can be done in partnership with trusted volunteers, but WMF needs to be able to make an ultimate determination after receiving community feedback regarding production changes that impact all users.
- We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
and enter constructive, open-ended conversations about the way forward, provided we can mutually agree to do so on the basis of the current consistent configuration -- for now. We would like to request a moratorium on any attempts to disable the feature during this conflict resolution process. The goal would be to make a final, cross-wiki determination regarding this specific feature, in partnership with the community, within at most 90 days.
With regard to the German Wikipedia situation, we’d like to know if stewards want to at all be involved in this process: In a situation like this, it can be helpful to have a third party support the conversation. Stewards are accountable to "valid community consensus within the bounds of the Foundation's goals" [3], which seems to be precisely the intersection of concerns at issue here. We would like to suggest an IRC meeting with stewards ASAP to talk about the specific question of stewards’ involvement, if any. If stewards prefer not to be involved, we understand, but it's probably a good idea to have a sync-up conversation regardless.
I hope we can move forward in good faith from here, and find better ways to work together. As Lila has expressed, we believe there is a need for a clear understanding of our role. It is as follows:
Managing software development, site configuration and deployment is a core WMF responsibility. The community leads in the development of content; the Wikimedia Foundation leads in the development of technology.
Because these processes are deeply interdependent, we need to develop better protocols for timely feedback and resolution of disagreements. At the same time Lila’s and the Board’s statements make it very clear that the WMF will not accept RfCs or votes as the sole determining factor in global software deployments.
This means that technology and UX changes should not be decided by vote or poll and then disabled at-will: where we disagree, we need to talk to each other (and yes, that means a more judicious application of RESOLVED WONTFIX on our end, as well!). We need to ensure a process where the community voice is heard earlier at critical junctions in the product development. All of this is consistent with the principle of "shared power" articulated in the Guiding Principles [4] approved by the Board of Trustees.
At the same time, as noted above and earlier, the superprotection feature should be replaced with a better mechanism for code review and deployment in the MediaWiki: namespace. This is discussed in [5] and ideas and suggestions are welcome. Let’s be upfront about control structures for production changes to avoid misunderstandings and ambiguity in the future.
We are exploring options on how to improve dispute resolution mechanisms -- whether it’s e.g. a standing working group or a better protocol for responding to RfCs and engaging in discussions. We've started a brainstorming page, here, which we hope will usefully inform the process of conflict resolution regarding German Wikipedia, as well, so we can arrive at a more concrete conflict resolution process soon. Your thoughts/suggestions are welcome, so we can (in NPOV style) look at different possibilities (e.g. workgroups, committees, votes, surveys) that have been discussed in the past:
https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
We’re absolutely not saying that WMF simply wants to be able to enforce its decisions: we completely understand there need to be mechanisms for the community to influence decisions and outcomes at all stages of the development and release of software. We need to arrive at this process together.
Again, we are sorry that this escalation occurred - and we hope we can move forward constructively from here.
Sincerely,
Erik
[1] https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbild...
[2] https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&am...
[3] https://meta.wikimedia.org/wiki/Stewards_policy
[4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shar...
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
-- Erik Möller VP of Engineering and Product Development, 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
I think those are wonderful steps and I really hope that the German wikipedians are ready for dialogue. Given the big number of people that might want to answer Lila's questions, shouldn't they be asked in a more public page, or organized in a more international/multilingual way, for a delimited time, and open to everyone? I think it is a perfect chance to ask broadly, but it needs to be organized and framed appropriately, or the answers won't be useful (or usable).
For the sake of simplicity, I would ask only two questions: What is the community that (each one of) you want to be in? How much effort do you want to put to make it happen?
It is short, but its answer involves expected rights, and expected obligations. If members expect to participate in decisions, then they have to make an effort to follow tech issues. If members expect a nice atmosphere, then they are also expected to contribute to that atmosphere by acting civil at all times. I didn't like to see so much of aggresivity and entitlement out of people that before didn't give a damn about notices.
At the moment it is not very clear what kind of community(ies) and participation is wanted, or if each of its supposed members is ready to make the necessary effort. In some places there are chapters, but that might not be the answer for everyone.
Cheers, Micru
On Tue, Aug 19, 2014 at 9:37 PM, Martin Rulsch martin.rulsch@wikimedia.de wrote:
Thank you, Erik, for your clarifications and understanding. Personally, I hope that most anger will calm down now although not everyone will agree with everything that was said or done (e.g. ignoring RfCs under some conditions, using superprotect instead of counting on local procedures to stop wheel warring) and we all can concentrate again on “working together to make Wikimedia projects are more welcome place for readers, authors, and anyone”. As this can only be done with mutual discussions, I'm looking forward to the intensified inclusion of the communities for future software developents as announced. Whether stewards can help here, I cannot tell, but I would abstain myself from getting involved for obvious reasons.
Cheers, Martin
2014-08-19 21:12 GMT+02:00 Erik Moeller erik@wikimedia.org:
Hi folks,
This is a response to Martin's note here:
https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
.. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward.
I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it.
I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page.
Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a "better hack" to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint.
Our processes clearly need to be improved to avoid these situations in the future. We recognize that simply rejecting a community request rather than resolving a conflict together is not the right answer. We’ve been listening to feedback, and we’ve come to the following conclusions:
- We intend to undertake a review of our present processes immediately
and propose a new approach that allows for feedback at more critical and relevant junctures in the next 90 days. This will be a transparent process that includes your voices.
- As the WMF, we need to improve the process for managing changes that
impact all users. That includes the MediaWiki: namespace. For WMF to fulfill its role of leading consistent improvements to the user experience across Wikimedia projects, we need to be able to review code and manage deployments. This can be done in partnership with trusted volunteers, but WMF needs to be able to make an ultimate determination after receiving community feedback regarding production changes that impact all users.
- We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
and enter constructive, open-ended conversations about the way forward, provided we can mutually agree to do so on the basis of the current consistent configuration -- for now. We would like to request a moratorium on any attempts to disable the feature during this conflict resolution process. The goal would be to make a final, cross-wiki determination regarding this specific feature, in partnership with the community, within at most 90 days.
With regard to the German Wikipedia situation, we’d like to know if stewards want to at all be involved in this process: In a situation like this, it can be helpful to have a third party support the conversation. Stewards are accountable to "valid community consensus within the bounds of the Foundation's goals" [3], which seems to be precisely the intersection of concerns at issue here. We would like to suggest an IRC meeting with stewards ASAP to talk about the specific question of stewards’ involvement, if any. If stewards prefer not to be involved, we understand, but it's probably a good idea to have a sync-up conversation regardless.
I hope we can move forward in good faith from here, and find better ways to work together. As Lila has expressed, we believe there is a need for a clear understanding of our role. It is as follows:
Managing software development, site configuration and deployment is a core WMF responsibility. The community leads in the development of content; the Wikimedia Foundation leads in the development of technology.
Because these processes are deeply interdependent, we need to develop better protocols for timely feedback and resolution of disagreements. At the same time Lila’s and the Board’s statements make it very clear that the WMF will not accept RfCs or votes as the sole determining factor in global software deployments.
This means that technology and UX changes should not be decided by vote or poll and then disabled at-will: where we disagree, we need to talk to each other (and yes, that means a more judicious application of RESOLVED WONTFIX on our end, as well!). We need to ensure a process where the community voice is heard earlier at critical junctions in the product development. All of this is consistent with the principle of "shared power" articulated in the Guiding Principles [4] approved by the Board of Trustees.
At the same time, as noted above and earlier, the superprotection feature should be replaced with a better mechanism for code review and deployment in the MediaWiki: namespace. This is discussed in [5] and ideas and suggestions are welcome. Let’s be upfront about control structures for production changes to avoid misunderstandings and ambiguity in the future.
We are exploring options on how to improve dispute resolution mechanisms -- whether it’s e.g. a standing working group or a better protocol for responding to RfCs and engaging in discussions. We've started a brainstorming page, here, which we hope will usefully inform the process of conflict resolution regarding German Wikipedia, as well, so we can arrive at a more concrete conflict resolution process soon. Your thoughts/suggestions are welcome, so we can (in NPOV style) look at different possibilities (e.g. workgroups, committees, votes, surveys) that have been discussed in the past:
https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
We’re absolutely not saying that WMF simply wants to be able to enforce its decisions: we completely understand there need to be mechanisms for the community to influence decisions and outcomes at all stages of the development and release of software. We need to arrive at this process together.
Again, we are sorry that this escalation occurred - and we hope we can move forward constructively from here.
Sincerely,
Erik
[1]
https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbild...
[2]
https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&am...
[3] https://meta.wikimedia.org/wiki/Stewards_policy
[4]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shar...
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
-- Erik Möller VP of Engineering and Product Development, 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
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
thank you erik, and martin for this! currently more than 600 persons express that this story should be resolved by reverting to the state before it started: https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Superschutz . while i thought originally "who cares", i do think now beeing sorry is expressed best by gesture not words.
rupert
On Tue, Aug 19, 2014 at 9:37 PM, Martin Rulsch martin.rulsch@wikimedia.de wrote:
Thank you, Erik, for your clarifications and understanding. Personally, I hope that most anger will calm down now although not everyone will agree with everything that was said or done (e.g. ignoring RfCs under some conditions, using superprotect instead of counting on local procedures to stop wheel warring) and we all can concentrate again on “working together to make Wikimedia projects are more welcome place for readers, authors, and anyone”. As this can only be done with mutual discussions, I'm looking forward to the intensified inclusion of the communities for future software developents as announced. Whether stewards can help here, I cannot tell, but I would abstain myself from getting involved for obvious reasons.
Cheers, Martin
2014-08-19 21:12 GMT+02:00 Erik Moeller erik@wikimedia.org:
Hi folks,
This is a response to Martin's note here: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
.. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward.
I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it.
I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page.
Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a "better hack" to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint.
Our processes clearly need to be improved to avoid these situations in the future. We recognize that simply rejecting a community request rather than resolving a conflict together is not the right answer. We’ve been listening to feedback, and we’ve come to the following conclusions:
- We intend to undertake a review of our present processes immediately
and propose a new approach that allows for feedback at more critical and relevant junctures in the next 90 days. This will be a transparent process that includes your voices.
- As the WMF, we need to improve the process for managing changes that
impact all users. That includes the MediaWiki: namespace. For WMF to fulfill its role of leading consistent improvements to the user experience across Wikimedia projects, we need to be able to review code and manage deployments. This can be done in partnership with trusted volunteers, but WMF needs to be able to make an ultimate determination after receiving community feedback regarding production changes that impact all users.
- We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
and enter constructive, open-ended conversations about the way forward, provided we can mutually agree to do so on the basis of the current consistent configuration -- for now. We would like to request a moratorium on any attempts to disable the feature during this conflict resolution process. The goal would be to make a final, cross-wiki determination regarding this specific feature, in partnership with the community, within at most 90 days.
With regard to the German Wikipedia situation, we’d like to know if stewards want to at all be involved in this process: In a situation like this, it can be helpful to have a third party support the conversation. Stewards are accountable to "valid community consensus within the bounds of the Foundation's goals" [3], which seems to be precisely the intersection of concerns at issue here. We would like to suggest an IRC meeting with stewards ASAP to talk about the specific question of stewards’ involvement, if any. If stewards prefer not to be involved, we understand, but it's probably a good idea to have a sync-up conversation regardless.
I hope we can move forward in good faith from here, and find better ways to work together. As Lila has expressed, we believe there is a need for a clear understanding of our role. It is as follows:
Managing software development, site configuration and deployment is a core WMF responsibility. The community leads in the development of content; the Wikimedia Foundation leads in the development of technology.
Because these processes are deeply interdependent, we need to develop better protocols for timely feedback and resolution of disagreements. At the same time Lila’s and the Board’s statements make it very clear that the WMF will not accept RfCs or votes as the sole determining factor in global software deployments.
This means that technology and UX changes should not be decided by vote or poll and then disabled at-will: where we disagree, we need to talk to each other (and yes, that means a more judicious application of RESOLVED WONTFIX on our end, as well!). We need to ensure a process where the community voice is heard earlier at critical junctions in the product development. All of this is consistent with the principle of "shared power" articulated in the Guiding Principles [4] approved by the Board of Trustees.
At the same time, as noted above and earlier, the superprotection feature should be replaced with a better mechanism for code review and deployment in the MediaWiki: namespace. This is discussed in [5] and ideas and suggestions are welcome. Let’s be upfront about control structures for production changes to avoid misunderstandings and ambiguity in the future.
We are exploring options on how to improve dispute resolution mechanisms -- whether it’s e.g. a standing working group or a better protocol for responding to RfCs and engaging in discussions. We've started a brainstorming page, here, which we hope will usefully inform the process of conflict resolution regarding German Wikipedia, as well, so we can arrive at a more concrete conflict resolution process soon. Your thoughts/suggestions are welcome, so we can (in NPOV style) look at different possibilities (e.g. workgroups, committees, votes, surveys) that have been discussed in the past:
https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
We’re absolutely not saying that WMF simply wants to be able to enforce its decisions: we completely understand there need to be mechanisms for the community to influence decisions and outcomes at all stages of the development and release of software. We need to arrive at this process together.
Again, we are sorry that this escalation occurred - and we hope we can move forward constructively from here.
Sincerely,
Erik
[1] https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbild...
[2] https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&am...
[3] https://meta.wikimedia.org/wiki/Stewards_policy
[4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shar...
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
-- Erik Möller VP of Engineering and Product Development, 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
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 19 August 2014 20:12, Erik Moeller erik@wikimedia.org wrote:
Thank your for your lengthy and considered post. It's clear that you and the WMF are seeking an amicable resolution, which is to be applauded.
Nonetheless, I'm having difficulty understanding how these two statements:
the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature,
We’re absolutely not saying that WMF simply wants to be able to enforce its decisions
can be reconciled.
On Tue, Aug 19, 2014 at 2:18 PM, Andy Mabbett andy@pigsonthewing.org.uk wrote:
Nonetheless, I'm having difficulty understanding how these two statements:
the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature,
We’re absolutely not saying that WMF simply wants to be able to enforce its decisions
can be reconciled.
Hi Andy,
I think it's clear that we need to develop a social contract that works for both parties. It doesn't work for communities if WMF simply declares an independent decision after a vote or RFC takes place (and yes, we have done so in this instance, and in others in the past). And from WMF's point of view (for reasons we have already articulated several times), it doesn't work to expect that WMF will implement every vote or RFC as-is without negotiation or discussion, and without room to take other factors into account.
When we talk about WMF's role, we need to distinguish between technical processes and outcomes.
In order to ensure consistency (including on issues like release planning, communications, bug reporting, etc.), WMF needs to manage the configuration and deployment _process_ (e.g. we flip the switches). In order to be able to exercise its leadership role in technology, it needs to have a say in the _outcome_, even if/when there are RFCs/votes asking us to disable a feature.
That to me is what the "shared power" guiding principle means -- we have clear roles and responsibilities, and we share in the decision-making.
When we disagree, we need to figure things out together, hear each other, and reason constructively. We don't have good conventions to do that right now. The "community vote -> WMF responds yes/no" or "community vote -> WMF responds with compromise" process is deeply insufficient and one-sided. It's a win/lose process rather than a process for working together.
We need to avoid getting to this place to begin with, but we also need to have better answers when we do, as I'm sure we inevitably will again from time to time.
This is what we're kicking around on the process ideas page: https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
Specifically, for something like Media Viewer, a lot of the issues we've had to work through relate to community-created technology (!) like custom templates used for certain purposes.
In these situations, sometimes the answer may be "Actually, what you did here with a template is a horrible idea and you probably shouldn't be doing it that way" -- and it's very hard for us to have these conversations honestly if it's in an oppositional context with a group of 200 people. And sometimes we need to support use cases that the community cares very much about, even if our initial reaction is "Do we _really_ have to do this?".
I think it needs to be much more tightly coupled, co-dependent working relationship through the product's lifecycle so we can work together honestly and with shared expertise.
That's true for VE, Flow, etc. as well -- we've tried the "light touch" community liaison model but I think we need something that brings us even closer together in day to day working practice. And my experience with Wikimedia volunteers is that there are almost always people willing to give their time if they feel it's actually valued in the process. Not tens of hours a week of course (that's why we have paid staff), but enough to stay informed and participate.
I could imagine having a process where, for any given project, there's a nomination and lightweight election process that lets people participate in associated communtiy task forces, which have weekly check-ins with the product team and actually meaningfully influence the roadmap. Is this something that people think could work? Has it worked well in other contexts?
I think the inter-dependent relationship on technology is really important to appreciate here -- it's something that's very unique to us (because of the countless templates, tools, customizations, etc. created by community members that interact with software we build). You can't have it both ways -- a crazy amount of customizability by the users themselves _and_ a very traditional relationship with software development ("ship a finished product to us and then we'll talk -- meanwhile let me add some parameters to this custom template that I expect your product will support from day 1").
Erik
[1] http://strategy.wikimedia.org/wiki/Task_force
On Tue, Aug 19, 2014 at 11:48 PM, Erik Moeller erik@wikimedia.org wrote:
I meant to say - the one example where we've tried targeted task forces that I can think of was this one, as part of the strategy process years ago. IIRC some of the task forces were pretty productive, though the integration of their work in the final end product was inconsistent. If product-related task forces actually were part of the process of influencing the backlog, examining data/findings, adding potential requirements, etc., that might be a compelling way to work together.
Erik,
I am curious to hear your thoughts about the proposed Technology Committee. That idea has some community support and had been discussed at some length on the WMF Board Noticeboard.
Pine On Aug 19, 2014 11:55 PM, "Erik Moeller" erik@wikimedia.org wrote:
On Tue, Aug 19, 2014 at 11:48 PM, Erik Moeller erik@wikimedia.org wrote:
I meant to say - the one example where we've tried targeted task forces that I can think of was this one, as part of the strategy process years ago. IIRC some of the task forces were pretty productive, though the integration of their work in the final end product was inconsistent. If product-related task forces actually were part of the process of influencing the backlog, examining data/findings, adding potential requirements, etc., that might be a compelling way to work together.
-- Erik Möller VP of Engineering and Product Development, 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
Pine W skrev 2014-08-20 09:32:
Erik,
I am curious to hear your thoughts about the proposed Technology Committee. That idea has some community support and had been discussed at some length on the WMF Board Noticeboard.
I second that question
The mediaviewer has never been an issue on the Swedish community. After our layout expert stated it was a good feature for the readers, we editors quickly learned to opt out and continue our editing
I also have no problem accepting that the communities do not decide over the UI to our readers. I also see very promising statement from Lila.
But i am missing the insight from both Erik and Lila that behind what is being discussed is a key concern. Who decides over the development. And here I believe, as I stated before, that a properly set up Technology Committe is needed in order to ease the tensions in the movement independent of iany mproved processes
Anders
On Wed, Aug 20, 2014 at 12:32 AM, Pine W wiki.pine@gmail.com wrote:
I am curious to hear your thoughts about the proposed Technology Committee. That idea has some community support and had been discussed at some length on the WMF Board Noticeboard.
I think it has merits if it's mostly used as a dispute resolution body. I think we need to have conflict resolution and escalation protocols for technology issues. Ideally WMF and a group of community members (whether in all cases truly representative or not) who are in conflict about a certain issue or outcome should be able to come to a consensus _between each other_. But when that's not possible, a group that is designed to be accountable to both WMF's mission and the community's consensus may need to be called upon to make a final call that is binding. In the current governance structure, that could be a group like the stewards. But it could be something new created for that purpose, if the community supports it.
This all presupposes that we collectively sign up for this whole "shared power" idea. It's a Board creation, a guiding principle, and all that. But that doesn't mean the community of people who've spent much of their lives building Wikimedia's projects as volunteers do believe in it. Maybe we should ask them, as a group, offering the pros and cons of that approach. It's very different futures -- a WMF that exists purely to do what communities ask it to, or a WMF that exists - in part - to look forward, close gaps, and help anticipate where we want to be 3, 5, 10 years from now. Irrespective of what my own take might be, both approaches do truly have their merits.
If we sign up collectively for "shared power", then today, we lack the mechanisms to implement that principle effectively, which is why we have conflicts over power which is not shared. And a community elected committee (perhaps with some additional representation of external expertise) might be one such mechanism, but if we don't have agreement on the basic idea, no mechanism will work. If we do agree on the principle, we can try and play with different implementations.
Erik
Am 22.08.2014 04:18 schrieb "Erik Moeller" erik@wikimedia.org:
On Wed, Aug 20, 2014 at 12:32 AM, Pine W wiki.pine@gmail.com wrote:
I am curious to hear your thoughts about the proposed Technology
Committee.
That idea has some community support and had been discussed at some
length
on the WMF Board Noticeboard.
I think it has merits if it's mostly used as a dispute resolution body. I think we need to have conflict resolution and escalation protocols for technology issues. Ideally WMF and a group of community members (whether in all cases truly representative or not) who are in conflict about a certain issue or outcome should be able to come to a consensus _between each other_. But when that's not possible, a group that is designed to be accountable to both WMF's mission and the community's consensus may need to be called upon to make a final call that is binding. In the current governance structure, that could be a group like the stewards. But it could be something new created for that purpose, if the community supports it.
This all presupposes that we collectively sign up for this whole "shared power" idea. It's a Board creation, a guiding principle, and all that. But that doesn't mean the community of people who've spent much of their lives building Wikimedia's projects as volunteers do believe in it. Maybe we should ask them, as a group, offering the pros and cons of that approach. It's very different futures -- a WMF that exists purely to do what communities ask it to, or a WMF that exists - in part - to look forward, close gaps, and help anticipate where we want to be 3, 5, 10 years from now. Irrespective of what my own take might be, both approaches do truly have their merits.
If we sign up collectively for "shared power", then today, we lack the mechanisms to implement that principle effectively, which is why we have conflicts over power which is not shared. And a community elected committee (perhaps with some additional representation of external expertise) might be one such mechanism, but if we don't have agreement on the basic idea, no mechanism will work. If we do agree on the principle, we can try and play with different implementations.
erik, let me ask a little in a devils advocate style:
is the conflict not only triggered by a deliverable which was not good enough? it did not include the authors in its use cases. the deliverable e.g. did include one click more for the authors workflow. which make hundreds of million clicks more if you sum it up.
in a standard business world we would see two scenarios: one, the ecyclopaedia britannica model. the authors would own the web domain, and sue the one who delivers bad software. the design needs to be properly specified beforehand to do this.
two, the facebook model. a company providing software to author as primary goal, and some mechanism built in to count reads. it does everything to increase it and would right from the start not deliver a complicated author experience.
the wmf tries to play both models. and it then suffers schizophrenia. the one delivering insufficient software does not get punished.
the reason is very simple: wikipedias content is of such high quality that one might leave it with little updates for the next 20 years. also, the readers experience is of such high quality that one might leave it for 20 years.
as somebody delivering software i understand your feelings quite well. you get dug into a hole and do not know a good way to get out.
introducing additional levels of complexity is a well known strategy. but we all know from our daily lives that we do tend to not like these levels and bureaucracy.
erik, please can you tell me one good reason what hinders you to tackle the source of all this, and rework the mediaviewer use case(s)?
devils adcocate mode out.
rupert
Hoi, I am happy for you that you think the reader experience is so great in the "devils advocate mode". In reality when I read a Wikipedia article because I want information all too often I hate what I get. The fact that it is the best around does not make me like the lack of clarity, the inconsistency of where information is found. All too often articles are written to overcome the power struggle around NPOV and suffer as a result.
Erik indicated that WMF has written software predominantly for editors and not for readers. All our projects suffer as a result from not getting to our intended audience and not achieving what we aim to achieve; share in the sum of all knowledge. Remember, our projects are first and foremost about providing information / knowledge to people. We are stuck in the process of producing the data that may once become information.
More focus on our end-users, even to the extend of "marketing" our data is what will get us significantly more readers and consequently achieve our goals more successfully. Thanks, GerardM
On 22 August 2014 07:54, rupert THURNER rupert.thurner@gmail.com wrote:
Am 22.08.2014 04:18 schrieb "Erik Moeller" erik@wikimedia.org:
On Wed, Aug 20, 2014 at 12:32 AM, Pine W wiki.pine@gmail.com wrote:
I am curious to hear your thoughts about the proposed Technology
Committee.
That idea has some community support and had been discussed at some
length
on the WMF Board Noticeboard.
I think it has merits if it's mostly used as a dispute resolution body. I think we need to have conflict resolution and escalation protocols for technology issues. Ideally WMF and a group of community members (whether in all cases truly representative or not) who are in conflict about a certain issue or outcome should be able to come to a consensus _between each other_. But when that's not possible, a group that is designed to be accountable to both WMF's mission and the community's consensus may need to be called upon to make a final call that is binding. In the current governance structure, that could be a group like the stewards. But it could be something new created for that purpose, if the community supports it.
This all presupposes that we collectively sign up for this whole "shared power" idea. It's a Board creation, a guiding principle, and all that. But that doesn't mean the community of people who've spent much of their lives building Wikimedia's projects as volunteers do believe in it. Maybe we should ask them, as a group, offering the pros and cons of that approach. It's very different futures -- a WMF that exists purely to do what communities ask it to, or a WMF that exists - in part - to look forward, close gaps, and help anticipate where we want to be 3, 5, 10 years from now. Irrespective of what my own take might be, both approaches do truly have their merits.
If we sign up collectively for "shared power", then today, we lack the mechanisms to implement that principle effectively, which is why we have conflicts over power which is not shared. And a community elected committee (perhaps with some additional representation of external expertise) might be one such mechanism, but if we don't have agreement on the basic idea, no mechanism will work. If we do agree on the principle, we can try and play with different implementations.
erik, let me ask a little in a devils advocate style:
is the conflict not only triggered by a deliverable which was not good enough? it did not include the authors in its use cases. the deliverable e.g. did include one click more for the authors workflow. which make hundreds of million clicks more if you sum it up.
in a standard business world we would see two scenarios: one, the ecyclopaedia britannica model. the authors would own the web domain, and sue the one who delivers bad software. the design needs to be properly specified beforehand to do this.
two, the facebook model. a company providing software to author as primary goal, and some mechanism built in to count reads. it does everything to increase it and would right from the start not deliver a complicated author experience.
the wmf tries to play both models. and it then suffers schizophrenia. the one delivering insufficient software does not get punished.
the reason is very simple: wikipedias content is of such high quality that one might leave it with little updates for the next 20 years. also, the readers experience is of such high quality that one might leave it for 20 years.
as somebody delivering software i understand your feelings quite well. you get dug into a hole and do not know a good way to get out.
introducing additional levels of complexity is a well known strategy. but we all know from our daily lives that we do tend to not like these levels and bureaucracy.
erik, please can you tell me one good reason what hinders you to tackle the source of all this, and rework the mediaviewer use case(s)?
devils adcocate mode out.
rupert _______________________________________________ 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
one more general level solution would be having more steps: proposing a solution to the community (checking for support), inviting willing testers, after positive feedback introducing to all logged in users, and after positive feedback propagating on the site as a whole.
Once the initial support for an idea is established, we can take for granted that the change should happen - but it should be up to feedback to see if the solution is ready, and not up to the developers' calendar (we've all seen what happens when the schedule is the in the case of visual editor premature launch).
I think that WMF perhaps takes way too little use of our community as testers, commentators, supporters. If the community was more involved in development plans, it would also not be surprised by solutions which perhaps are important and wise in the log term, but still should not jump out of the box and be perceived as forced.
I don't think it makes any sense to perceive WMF as just a servant. But how should we perceive the community? Is it a disorganized mass with no uniform voice, that should be shepherded into accepting solutions? Is it a valuable resource? Is it a full partner in planning, testing and implementing the solutions? I think that a lot of the latter is missing, and the fault is on both sides. But it is mainly up to WMF to change it, as WMF has the structures, staff, and resources to propose procedures there.
just my two cents, anyway.
dj "pundit"
On Fri, Aug 22, 2014 at 7:54 AM, rupert THURNER rupert.thurner@gmail.com wrote:
Am 22.08.2014 04:18 schrieb "Erik Moeller" erik@wikimedia.org:
On Wed, Aug 20, 2014 at 12:32 AM, Pine W wiki.pine@gmail.com wrote:
I am curious to hear your thoughts about the proposed Technology
Committee.
That idea has some community support and had been discussed at some
length
on the WMF Board Noticeboard.
I think it has merits if it's mostly used as a dispute resolution body. I think we need to have conflict resolution and escalation protocols for technology issues. Ideally WMF and a group of community members (whether in all cases truly representative or not) who are in conflict about a certain issue or outcome should be able to come to a consensus _between each other_. But when that's not possible, a group that is designed to be accountable to both WMF's mission and the community's consensus may need to be called upon to make a final call that is binding. In the current governance structure, that could be a group like the stewards. But it could be something new created for that purpose, if the community supports it.
This all presupposes that we collectively sign up for this whole "shared power" idea. It's a Board creation, a guiding principle, and all that. But that doesn't mean the community of people who've spent much of their lives building Wikimedia's projects as volunteers do believe in it. Maybe we should ask them, as a group, offering the pros and cons of that approach. It's very different futures -- a WMF that exists purely to do what communities ask it to, or a WMF that exists - in part - to look forward, close gaps, and help anticipate where we want to be 3, 5, 10 years from now. Irrespective of what my own take might be, both approaches do truly have their merits.
If we sign up collectively for "shared power", then today, we lack the mechanisms to implement that principle effectively, which is why we have conflicts over power which is not shared. And a community elected committee (perhaps with some additional representation of external expertise) might be one such mechanism, but if we don't have agreement on the basic idea, no mechanism will work. If we do agree on the principle, we can try and play with different implementations.
erik, let me ask a little in a devils advocate style:
is the conflict not only triggered by a deliverable which was not good enough? it did not include the authors in its use cases. the deliverable e.g. did include one click more for the authors workflow. which make hundreds of million clicks more if you sum it up.
in a standard business world we would see two scenarios: one, the ecyclopaedia britannica model. the authors would own the web domain, and sue the one who delivers bad software. the design needs to be properly specified beforehand to do this.
two, the facebook model. a company providing software to author as primary goal, and some mechanism built in to count reads. it does everything to increase it and would right from the start not deliver a complicated author experience.
the wmf tries to play both models. and it then suffers schizophrenia. the one delivering insufficient software does not get punished.
the reason is very simple: wikipedias content is of such high quality that one might leave it with little updates for the next 20 years. also, the readers experience is of such high quality that one might leave it for 20 years.
as somebody delivering software i understand your feelings quite well. you get dug into a hole and do not know a good way to get out.
introducing additional levels of complexity is a well known strategy. but we all know from our daily lives that we do tend to not like these levels and bureaucracy.
erik, please can you tell me one good reason what hinders you to tackle the source of all this, and rework the mediaviewer use case(s)?
devils adcocate mode out.
rupert _______________________________________________ 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 Thu, Aug 21, 2014 at 10:54 PM, rupert THURNER rupert.thurner@gmail.com wrote:
is the conflict not only triggered by a deliverable which was not good enough? it did not include the authors in its use cases. the deliverable e.g. did include one click more for the authors workflow. which make hundreds of million clicks more if you sum it up.
(...)
erik, please can you tell me one good reason what hinders you to tackle the source of all this, and rework the mediaviewer use case(s)?
Rupert, I always like a good devil's advocate, especially when it doesn't sound devil-ish at all. ;-)
Let's start with some facts:
- The MediaViewer rollout was very smooth until the deployments to German Wikipedia, English Wikipedia and Wikimedia Commons. There could be many reasons for that -- but it's a fact nonetheless. I do see little evidence that users in other communities are especially unhappy about the feature (leaving aside the politics of it now). I would be very curious what reason people do attribute that difference to, however (understanding that Commons is very different from the Wikipedia use case).
- As a user, it's trivial to disable Media Viewer. Not quite as easy as we want it to be, but literally a scroll-down and click away, which is more than you can say about most MediaWiki preferences. It's also trivial to skip on a case-by-case basis -- just open an image in a new tab.
- Even on de.wp, if you read the comments from people supporting the feature, in the poll leading up to Wikimania (a minority, but not a tiny one - 72 voters in the poll [1]), you'll notice that the reader/editor distinction isn't such a clear one. While many users voted "on behalf of" readers, others pointed out that they themselves like the fast access to the picture and switch back and forth as needed (opening images in the background when they want to skip the viewer). That was also what we heard from folks at Wikimania, for example, and the generally low opt-out rates support it.
- The criticism isn't just about that -- it's about a large number of mostly individually small issues. Generally, the idea that we effectively "munge" some of the metadata by displaying a machine-readable subset below the fold is viewed very negatively, because 1) it doesn't reflect all the available information, 2) it makes it harder for users to discover the File: page, and potentially edit it.
Users who oppose the feature do not always do so strictly for personal reasons, or many of them would probably be fine to disable it for themselves; they often have criticisms that go beyond their own needs and extend into areas like re-use, licensing information, and creating an environment that draws people into contributing. Editors are not blind to the needs of readers, they just have a low tolerance for imperfections and would prefer to see a product that already addresses all these concerns at the time of release.
We understand all that. We've read virtually every comment (surveys, feedback page, votes/RFCs, etc.). I'm not normally as familiar with every product WMF works on but by now I know many of the internals of the damn thing (though Mark probably thanks the GNU deities daily that I've not submitted any patches yet).
Change aversion is often [[loss aversion]] - people prefer avoiding losses to making gains, which is why the positive benefits of a new feature tend to be overshadowed quickly by any shortcomings, even if they are (objectively speaking) comparatively small and easily addressed.
It's true that we (WMF) should have done more early on to specifically help with template cleanup -- we made some efforts to add machine-readable data to key templates and rally community help, but they were insufficient. This is not strictly an engineering problem - the CommonsMetadata extension works just fine, the documentation is clear, etc. It's an outreach effort that should have accompanied the rollout more systematically. With that said, the needed fixes to templates are fairly trivial (we just worked with de.wp to implement one), while immediately resolving issues with license display for large numbers of files, and help many other applications beyond the viewer.
In addition, as previously noted [2], we're testing some pretty significant changes of the UI, including a much more prominent integration of the File: page link, identifying it clearly as the canonical source of metadata.
We're not saying "You're wrong, we're right" - just that we understand the issues pretty well, and we think the main concerns can likely be addressed fairly quickly (and some already have been). In general, we believe that there needs to be at least some allowance for iterating on a release, rather than forcing an immediate revert. If we reason things through together, try things out, look at the results, and we're wrong, well, let's just turn the thing off completely rather than making half-assed config changes in one wiki.
Mind you, in responding to the poll on de.wp, we didn't say "Thanks, but no thanks" - we gave a detailed rationale, and we felt (internally) that we were being reasonable in doing so, not that we were being jerks, which explains at least partially why we then felt maintaing that decision was appropriate. But I understand that even the simple dynamic of "valid community process" -> "decision by WMF that's not entirely consistent with it" leads to escalation, which is why we're arguing for better process when we disagree.
Cheers, Erik
[1] As a side note, in these conflicts, one of the things I'm most frustrated by is that those voices of proponents tend to get lost. Once it becomes about the power dynamic, the rational, supportive arguments _by community members_ appear to carry no weight whatsoever, and if anything, they risk being portrayed as stooges supporting the Evil Bureaucracy. That doesn't strike me as consistent with the idea of "consensus" either.
[2] https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073861.html
On 22.08.2014 09:22, Erik Moeller wrote:
- The MediaViewer rollout was very smooth until the deployments to
German Wikipedia, English Wikipedia and Wikimedia Commons. There could be many reasons for that -- but it's a fact nonetheless. I do see little evidence that users in other communities are especially unhappy about the feature (leaving aside the politics of it now). I would be very curious what reason people do attribute that difference to, however (understanding that Commons is very different from the Wikipedia use case).
This may or may not correlate with a deep commitment to a) the licenses, b) quality.
- The criticism isn't just about that -- it's about a large number of
mostly individually small issues. Generally, the idea that we effectively "munge" some of the metadata by displaying a machine-readable subset below the fold is viewed very negatively, because 1) it doesn't reflect all the available information, 2) it makes it harder for users to discover the File: page, and potentially edit it.
If it does not reflect the license information it is broken.
The license is paramount. We can not accept any kind of software that hands out "reuse information" that does not display the photographer's name and the license (with link to the license text).
We do not want a default setting, that does not show extensive descriptions, map legends, image annotations and the like. All that is content we created for the readers. You must not block our readers from this content.
MV is broken. It is not ready to be deployed. Not by far. Take it back and fix it.
In theory I can see a working MV. I can even imagine a working Visual Editor, but am very skeptical about it. I can not imagine Flow to work, ever. This one needs to be abandoned now.
Eric, your department has an abysmal record. You have wasted millions on software that started with the wrong framework and is not working after years and years of development. Please think about yourself, not about the communities if you want to understand about the conflicts at hand.
Henning
Hoi, I am so happy that you know so well that all the millions have been wasted. As so often, an opinion is just that. When you want to learn about the effect of the development done, it may be useful to look a bit further afield. Mobile is one area where the development proves really effective. Without it our numbers of readers would be down. It is also where the number of new editors are happening.
When your idea of editing Wikipedia is business as usual, you have lost many people because the experience is awful.
So when I am to accept your argument that the framework is wrong. I will agree with you when it means that we migrate from the awful framework we have used for too long. It is exactly the Visual Editor and the Media Viewer that make sense to our users. Commons as it is is so bad as an experience that people like me who are committed to WMF do not use it.
Now what do we aim to achieve? Keeping you happy or making sure we have a public ??? Thanks, GerardM
On 22 August 2014 13:05, Henning Schlottmann h.schlottmann@gmx.net wrote:
On 22.08.2014 09:22, Erik Moeller wrote:
- The MediaViewer rollout was very smooth until the deployments to
German Wikipedia, English Wikipedia and Wikimedia Commons. There could be many reasons for that -- but it's a fact nonetheless. I do see little evidence that users in other communities are especially unhappy about the feature (leaving aside the politics of it now). I would be very curious what reason people do attribute that difference to, however (understanding that Commons is very different from the Wikipedia use case).
This may or may not correlate with a deep commitment to a) the licenses, b) quality.
- The criticism isn't just about that -- it's about a large number of
mostly individually small issues. Generally, the idea that we effectively "munge" some of the metadata by displaying a machine-readable subset below the fold is viewed very negatively, because 1) it doesn't reflect all the available information, 2) it makes it harder for users to discover the File: page, and potentially edit it.
If it does not reflect the license information it is broken.
The license is paramount. We can not accept any kind of software that hands out "reuse information" that does not display the photographer's name and the license (with link to the license text).
We do not want a default setting, that does not show extensive descriptions, map legends, image annotations and the like. All that is content we created for the readers. You must not block our readers from this content.
MV is broken. It is not ready to be deployed. Not by far. Take it back and fix it.
In theory I can see a working MV. I can even imagine a working Visual Editor, but am very skeptical about it. I can not imagine Flow to work, ever. This one needs to be abandoned now.
Eric, your department has an abysmal record. You have wasted millions on software that started with the wrong framework and is not working after years and years of development. Please think about yourself, not about the communities if you want to understand about the conflicts at hand.
Henning
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
Hello,
I am very grateful for Gerards remarks.
Sometimes I see a lot of black/white-thinking in the Wikimedia movement, with statements such as "this is all bad" (and, occasionally, "this is all good"). I am more comfortable with shades of grey, they don't have to be fifty, but at least 5 or 10. On a scale to five, the Visual Editor might have been "2" in 2013, now it looks to me like "3" or "4". Not good enough? :-)
Some people in the movement and especially in the communities have found their way of doing things and are happy with it, they don't want to have anything changed and don't see the need for it. That is a legitimate feeling and attitude, but other people allow themselves to point out the downsides. Some find it very difficult to tolerate that, because they don't want their world to change.
Software is not the solution for everything, but sometimes it helps to make some things better. Wikipedia editing will always remain a hobby for a very small part of the general population. But those people who want to edit should at least not find technology a treshold. There are other tresholds, such as the often lack of civility in the communities, but that is no reason not to tackle the technological one. (People in my classes wonder why Wikipedia editing is so antiquated, it reminds them of Word Perfect in the 90s.)
The real question to me seems to be: who exactly should decide on what software is implemented, what would be a practicable solution that keeps things going and includes the stakeholders.
Kind regards Ziko
2014-08-24 11:07 GMT+02:00 Gerard Meijssen gerard.meijssen@gmail.com:
Hoi, I am so happy that you know so well that all the millions have been wasted. As so often, an opinion is just that. When you want to learn about the effect of the development done, it may be useful to look a bit further afield. Mobile is one area where the development proves really effective. Without it our numbers of readers would be down. It is also where the number of new editors are happening.
When your idea of editing Wikipedia is business as usual, you have lost many people because the experience is awful.
So when I am to accept your argument that the framework is wrong. I will agree with you when it means that we migrate from the awful framework we have used for too long. It is exactly the Visual Editor and the Media Viewer that make sense to our users. Commons as it is is so bad as an experience that people like me who are committed to WMF do not use it.
Now what do we aim to achieve? Keeping you happy or making sure we have a public ??? Thanks, GerardM
On 22 August 2014 13:05, Henning Schlottmann h.schlottmann@gmx.net wrote:
On 22.08.2014 09:22, Erik Moeller wrote:
- The MediaViewer rollout was very smooth until the deployments to
German Wikipedia, English Wikipedia and Wikimedia Commons. There could be many reasons for that -- but it's a fact nonetheless. I do see little evidence that users in other communities are especially unhappy about the feature (leaving aside the politics of it now). I would be very curious what reason people do attribute that difference to, however (understanding that Commons is very different from the Wikipedia use case).
This may or may not correlate with a deep commitment to a) the licenses, b) quality.
- The criticism isn't just about that -- it's about a large number of
mostly individually small issues. Generally, the idea that we effectively "munge" some of the metadata by displaying a machine-readable subset below the fold is viewed very negatively, because 1) it doesn't reflect all the available information, 2) it makes it harder for users to discover the File: page, and potentially edit it.
If it does not reflect the license information it is broken.
The license is paramount. We can not accept any kind of software that hands out "reuse information" that does not display the photographer's name and the license (with link to the license text).
We do not want a default setting, that does not show extensive descriptions, map legends, image annotations and the like. All that is content we created for the readers. You must not block our readers from this content.
MV is broken. It is not ready to be deployed. Not by far. Take it back and fix it.
In theory I can see a working MV. I can even imagine a working Visual Editor, but am very skeptical about it. I can not imagine Flow to work, ever. This one needs to be abandoned now.
Eric, your department has an abysmal record. You have wasted millions on software that started with the wrong framework and is not working after years and years of development. Please think about yourself, not about the communities if you want to understand about the conflicts at hand.
Henning
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
hi,
On Sun, Aug 24, 2014 at 11:07 AM, Gerard Meijssen <gerard.meijssen@gmail.com
wrote:
Now what do we aim to achieve? Keeping you happy or making sure we have a public ???
simply put: both. We need readers just as much as we need the free labor of editors/volunteers.
I don't think it makes any sense to have a discussion about the "wasted millions". First, in software development there is always some inevitable waste, just because of the nature of this endeavor. Second, many projects which start with mixed reception are getting better (and I have high hope that the visual editor is one of them!). Third, for an IT organization of this caliber and traffic, as well as the budget, there are impressive results in many areas (including, but not limited to, mobile website - at least for viewers, as editing is a different story).
The real problem here, in my view, is creating an organizational framework that will allow to incorporate the community much more into planning, early development, alpha and beta testing, and finally implementation of all new features and tools (in a way which does not rely on IT schedules only, but also on feedback from the communities). It is up to WMF to create and provide such framework, as our community as a whole does not have any institutionalized representation or voice (which is part of the issue; one the one hand it is easy to discard whatever people from the community say, as they are random individuals, and on the other it must be deeply frustrating to never be sure what the community reaction will be). Some people are suggesting stewards as the good group to start with - I'm afraid stewards are not the best ones to go to. Stewards act mainly as highly trusted, experienced individuals. They do not represent their local communities in any way. Also, they do not necessarily have the best skills for the task, and they do not form a cooperating team, in general.
One of the unbearable signs of bureaucracy is setting up committees, but here a volunteer-driven, democratic task force could actually make some sense, perhaps. Look at it this way - we elect admins, crats, checkusers, oversighters, stewards. All these roles are only technical. Perhaps at some point we should think of community representation as well (and not in the sense of leadership, but in the sense of liaisons, testers, people responsible for smoother communication).
My experience within the FDC has shown that volunteer-driven bodies are quite effective at such tasks, when provided with necessary organizational support.
best,
dariusz "pundit"
Hoi, In the metrics meeting, a presentation was given that showed that mobile editing is really starting to happen. It is happening to the extend where new editors are predominantly mobile editors.
When I asked my question "do we need to keep you happy" I specifically targeted the vitriolic parts of our community. In my experience it it the part that is conservative, not willing to listen, not open to change and not willing to consider what is important to others.At Wikimania one of the presenters indicated that he was willing to contribute to Wikidata. This was not accepted because "someone in the community is really involved in this subject and he had to have a say". This was one major person probably walking away for ever who is hugely important in science and open data. The user interface for selecting fonts is abysmal because the "community" decided that what was implemented looked cluttered. Only seven percent of the world population is dyslexic and they do NOT find Wikipedia easier to read as a result.
Really, what is important to some people in the "community" is not necessarily beneficial at all. The lack of conversation the ease of making demands and not appreciating that our aim is to "share in the sum of all knowledge" means that many retarded points of view abound.
Erik indicated that he is willing to talk and come to a workable compromise. However, we do need change and we need it badly. When this is not understood, I am sorry to say, those who fail to understand this are a problem, a problem that is increasingly cancelling out their future value. Thanks, Gerard
On 24 August 2014 12:49, Dariusz Jemielniak darekj@alk.edu.pl wrote:
hi,
On Sun, Aug 24, 2014 at 11:07 AM, Gerard Meijssen < gerard.meijssen@gmail.com
wrote:
Now what do we aim to achieve? Keeping you happy or making sure we have a public ???
simply put: both. We need readers just as much as we need the free labor of editors/volunteers.
I don't think it makes any sense to have a discussion about the "wasted millions". First, in software development there is always some inevitable waste, just because of the nature of this endeavor. Second, many projects which start with mixed reception are getting better (and I have high hope that the visual editor is one of them!). Third, for an IT organization of this caliber and traffic, as well as the budget, there are impressive results in many areas (including, but not limited to, mobile website - at least for viewers, as editing is a different story).
The real problem here, in my view, is creating an organizational framework that will allow to incorporate the community much more into planning, early development, alpha and beta testing, and finally implementation of all new features and tools (in a way which does not rely on IT schedules only, but also on feedback from the communities). It is up to WMF to create and provide such framework, as our community as a whole does not have any institutionalized representation or voice (which is part of the issue; one the one hand it is easy to discard whatever people from the community say, as they are random individuals, and on the other it must be deeply frustrating to never be sure what the community reaction will be). Some people are suggesting stewards as the good group to start with - I'm afraid stewards are not the best ones to go to. Stewards act mainly as highly trusted, experienced individuals. They do not represent their local communities in any way. Also, they do not necessarily have the best skills for the task, and they do not form a cooperating team, in general.
One of the unbearable signs of bureaucracy is setting up committees, but here a volunteer-driven, democratic task force could actually make some sense, perhaps. Look at it this way - we elect admins, crats, checkusers, oversighters, stewards. All these roles are only technical. Perhaps at some point we should think of community representation as well (and not in the sense of leadership, but in the sense of liaisons, testers, people responsible for smoother communication).
My experience within the FDC has shown that volunteer-driven bodies are quite effective at such tasks, when provided with necessary organizational support.
best,
dariusz "pundit"
--
prof. dr hab. Dariusz Jemielniak kierownik katedry Zarządzania Międzynarodowego i centrum badawczego CROW Akademia Leona Koźmińskiego http://www.crow.alk.edu.pl
członek Akademii Młodych Uczonych Polskiej Akademii Nauk _______________________________________________ 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 have heard very few people say "don't ever change the interface." I have heard people say "don't force an interface change on me that I don't think is an improvement."
VE was a good example. The sentiment of the community wasn't that VE''s concept is wrong, it's that the implementation and rollout had major deficiencies.
The MV issue is larger than than the usual editor-focused interface change because it impacts readers as well as editors, and there were issues with the display of licenses to readers. Personally I feel that the MV issues are fixable but the rollout should have been handled differently, and I am glad that the community and WMF both want to avoid repeating rollout problems again and again.
Pine
On Sun, Aug 24, 2014 at 4:48 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, In the metrics meeting, a presentation was given that showed that mobile editing is really starting to happen. It is happening to the extend where new editors are predominantly mobile editors.
When I asked my question "do we need to keep you happy" I specifically targeted the vitriolic parts of our community. In my experience it it the part that is conservative, not willing to listen, not open to change and not willing to consider what is important to others.At Wikimania one of the presenters indicated that he was willing to contribute to Wikidata. This was not accepted because "someone in the community is really involved in this subject and he had to have a say". This was one major person probably walking away for ever who is hugely important in science and open data. The user interface for selecting fonts is abysmal because the "community" decided that what was implemented looked cluttered. Only seven percent of the world population is dyslexic and they do NOT find Wikipedia easier to read as a result.
Really, what is important to some people in the "community" is not necessarily beneficial at all. The lack of conversation the ease of making demands and not appreciating that our aim is to "share in the sum of all knowledge" means that many retarded points of view abound.
Erik indicated that he is willing to talk and come to a workable compromise. However, we do need change and we need it badly. When this is not understood, I am sorry to say, those who fail to understand this are a problem, a problem that is increasingly cancelling out their future value. Thanks, Gerard
On 24 August 2014 12:49, Dariusz Jemielniak darekj@alk.edu.pl wrote:
hi,
On Sun, Aug 24, 2014 at 11:07 AM, Gerard Meijssen < gerard.meijssen@gmail.com
wrote:
Now what do we aim to achieve? Keeping you happy or making sure we
have a
public ???
simply put: both. We need readers just as much as we need the free labor
of
editors/volunteers.
I don't think it makes any sense to have a discussion about the "wasted millions". First, in software development there is always some inevitable waste, just because of the nature of this endeavor. Second, many projects which start with mixed reception are getting better (and I have high hope that the visual editor is one of them!). Third, for an IT organization of this caliber and traffic, as well as the budget, there are impressive results in many areas (including, but not limited to, mobile website - at least for viewers, as editing is a different story).
The real problem here, in my view, is creating an organizational
framework
that will allow to incorporate the community much more into planning,
early
development, alpha and beta testing, and finally implementation of all
new
features and tools (in a way which does not rely on IT schedules only,
but
also on feedback from the communities). It is up to WMF to create and provide such framework, as our community as a whole does not have any institutionalized representation or voice (which is part of the issue;
one
the one hand it is easy to discard whatever people from the community
say,
as they are random individuals, and on the other it must be deeply frustrating to never be sure what the community reaction will be). Some people are suggesting stewards as the good group to start with - I'm
afraid
stewards are not the best ones to go to. Stewards act mainly as highly trusted, experienced individuals. They do not represent their local communities in any way. Also, they do not necessarily have the best
skills
for the task, and they do not form a cooperating team, in general.
One of the unbearable signs of bureaucracy is setting up committees, but here a volunteer-driven, democratic task force could actually make some sense, perhaps. Look at it this way - we elect admins, crats, checkusers, oversighters, stewards. All these roles are only technical. Perhaps at
some
point we should think of community representation as well (and not in the sense of leadership, but in the sense of liaisons, testers, people responsible for smoother communication).
My experience within the FDC has shown that volunteer-driven bodies are quite effective at such tasks, when provided with necessary
organizational
support.
best,
dariusz "pundit"
--
prof. dr hab. Dariusz Jemielniak kierownik katedry Zarządzania Międzynarodowego i centrum badawczego CROW Akademia Leona Koźmińskiego http://www.crow.alk.edu.pl
członek Akademii Młodych Uczonych Polskiej Akademii Nauk _______________________________________________ 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 08/24/2014 11:19 PM, Pine W wrote:
I have heard people say "don't force an interface change on me that I don't think is an improvement."
I do not recall a recent interface change deployment that wasn't accompanied with, at the very least, some method of opting out. Did I miss one?
-- Marc
I've found one very recently, actually, or at least if there is an opt-out it's very opaque.
I use the desktop interface on my mobile. I've no intention of ever changing that. There used to be an option that permanently disabled mobile interface for a given browser (I presume via a persistent cookie, as it worked even when I wasn't logged in), but now I have to switch back to desktop every day or so. There are several requests at https://en.wikipedia.org/wiki/Help_talk:Mobile_access#Turn_mobile_access_off for a way to disable the mobile interface, but no answers as to how to do that or if that's even supported anymore.
I'm sure I could hack around it by changing useragents or the like, but I shouldn't -have- to use some hacky solution to it. If I don't ever want to use the mobile interface, provide a way for me to say that and leave the change permanent (at least until I decide otherwise).
So either I'm missing something (and I'm not the only one), or yeah, you missed one.
Todd
On Sun, Aug 24, 2014 at 10:07 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 08/24/2014 11:19 PM, Pine W wrote:
I have heard people say "don't force an interface change on me that I don't
think
is an improvement."
I do not recall a recent interface change deployment that wasn't accompanied with, at the very least, some method of opting out. Did I miss one?
-- Marc
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
That sounds like a bug to me. Have you filed a bug in Bugzilla to be sure that the Mobile Web team is aware?
Dan
On 24 August 2014 21:13, Todd Allen toddmallen@gmail.com wrote:
I've found one very recently, actually, or at least if there is an opt-out it's very opaque.
I use the desktop interface on my mobile. I've no intention of ever changing that. There used to be an option that permanently disabled mobile interface for a given browser (I presume via a persistent cookie, as it worked even when I wasn't logged in), but now I have to switch back to desktop every day or so. There are several requests at
https://en.wikipedia.org/wiki/Help_talk:Mobile_access#Turn_mobile_access_off for a way to disable the mobile interface, but no answers as to how to do that or if that's even supported anymore.
I'm sure I could hack around it by changing useragents or the like, but I shouldn't -have- to use some hacky solution to it. If I don't ever want to use the mobile interface, provide a way for me to say that and leave the change permanent (at least until I decide otherwise).
So either I'm missing something (and I'm not the only one), or yeah, you missed one.
Todd
On Sun, Aug 24, 2014 at 10:07 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 08/24/2014 11:19 PM, Pine W wrote:
I have heard people say "don't force an interface change on me that I don't
think
is an improvement."
I do not recall a recent interface change deployment that wasn't accompanied with, at the very least, some method of opting out. Did I miss one?
-- Marc
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
Dan,
Filed as 69967 on Bugzilla. I'm glad you clarified that; to be quite honest, the timing here (starting about a couple weeks ago) looked to me to be yet another "You'll use it and you'll LIKE IT!", especially given the lack of response at the documentation page. Sorry if I jumped to a conclusion.
Todd
On Sun, Aug 24, 2014 at 10:19 PM, Dan Garry dgarry@wikimedia.org wrote:
That sounds like a bug to me. Have you filed a bug in Bugzilla to be sure that the Mobile Web team is aware?
Dan
On 24 August 2014 21:13, Todd Allen toddmallen@gmail.com wrote:
I've found one very recently, actually, or at least if there is an
opt-out
it's very opaque.
I use the desktop interface on my mobile. I've no intention of ever changing that. There used to be an option that permanently disabled
mobile
interface for a given browser (I presume via a persistent cookie, as it worked even when I wasn't logged in), but now I have to switch back to desktop every day or so. There are several requests at
https://en.wikipedia.org/wiki/Help_talk:Mobile_access#Turn_mobile_access_off
for a way to disable the mobile interface, but no answers as to how to do that or if that's even supported anymore.
I'm sure I could hack around it by changing useragents or the like, but I shouldn't -have- to use some hacky solution to it. If I don't ever want
to
use the mobile interface, provide a way for me to say that and leave the change permanent (at least until I decide otherwise).
So either I'm missing something (and I'm not the only one), or yeah, you missed one.
Todd
On Sun, Aug 24, 2014 at 10:07 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 08/24/2014 11:19 PM, Pine W wrote:
I have heard people say "don't force an interface change on me that I don't
think
is an improvement."
I do not recall a recent interface change deployment that wasn't accompanied with, at the very least, some method of opting out. Did I miss one?
-- Marc
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
-- 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 24 August 2014 21:36, Todd Allen toddmallen@gmail.com wrote:
Filed as 69967 on Bugzilla.
Great, thanks! I suspect this is a problem with MobileFrontend, so I've moved the bug into that product so that people will see it. I'll keep my eye on the bug, either way.
I'm glad you clarified that; to be quite
honest, the timing here (starting about a couple weeks ago) looked to me to be yet another "You'll use it and you'll LIKE IT!", especially given the lack of response at the documentation page. Sorry if I jumped to a conclusion.
The Mobile Apps team typically receives messages from volunteers through the Village Pumps (in which case the Community Liaisons know to ping me) or by email directly into mobile-l. I personally never would've thought to check that talk page for comments and questions. I suspect the same is true of the Mobile Web team.
I'll update the header on that talk page to point to [[WP:VPT]] so that people leave their comments in the right place.
Dan
On Mon, Aug 25, 2014 at 2:07 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 08/24/2014 11:19 PM, Pine W wrote:
I have heard people say "don't force an interface change on me that I don't think is an improvement."
I do not recall a recent interface change deployment that wasn't accompanied with, at the very least, some method of opting out. Did I miss one?
Did you try opting out of MediaViewer on the mobile version?
I think the response that I received confirmed it wasnt possible.
Per-user opt-out aside, the WMF was still forcing an interface change onto the community at large. With VE, the WMF needed the community to add TemplateData to all templates to help the newbies who were using VE; with MV, the WMF needed the community to 'tag' images which shouldnt be shown in the MV, and there is an ongoing need for the community to 'fix' the image page syntax in order for the information to display correctly to the end users in MV.
In both cases, significant amounts of volunteer time is required to avoid a bad user experience. WMF needs 'buy-in' for that, if it wants volunteers to be happy volunteers while doing mundane work to make the new software suck less.
-- John Vandenberg
On 25.08.2014 06:07, Marc A. Pelletier wrote:
On 08/24/2014 11:19 PM, Pine W wrote:
I have heard people say "don't force an interface change on me that I don't think is an improvement."
I do not recall a recent interface change deployment that wasn't accompanied with, at the very least, some method of opting out. Did I miss one?
-- Marc
FLOW?
Unless you count leaving the project as opt-out.
Cheers Yaroslav
On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW?
Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment.
But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless.
That also explains the very deliberate development and feedback loop.
-- Marc
I'm not sure the term "loop" is appropriate. So far, I see little evidence that feedback provided [1] is making any appreciable difference.
[1] https://en.wikipedia.org/wiki/Wikipedia_talk:Flow
On Fri, Sep 5, 2014 at 5:34 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW?
Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment.
But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless.
That also explains the very deliberate development and feedback loop.
-- Marc
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
Andreas, what would you do process-wise from the perspective of the WMF and/or the broader community to improve communication and its impact on development of Flow?
,Wil
On Fri, Sep 5, 2014 at 10:11 AM, Andreas Kolbe jayen466@gmail.com wrote:
I'm not sure the term "loop" is appropriate. So far, I see little evidence that feedback provided [1] is making any appreciable difference.
[1] https://en.wikipedia.org/wiki/Wikipedia_talk:Flow
On Fri, Sep 5, 2014 at 5:34 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW?
Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment.
But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless.
That also explains the very deliberate development and feedback loop.
-- Marc
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
This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle:
1) Is the WMF working with the community as closely and substantially as possible to make sure Flow is ready for primetime?
2) Is the community preparing itself for a major change, not only in interface, but to some degree in wiki-philosophy about how discussions are conducted- not to mention the notion that, while wiki software can do almost anything involving asynchronous online communication, it can't do everything as well as other interfaces?
I think Flow will be particularly challenging. I deployed Liquid Threads on another site. I liked the threaded interface, as did others. But overall it was roundly rejected because it was harder to search (I only found out you have to add the namespace to the searchable namespace in LocalSettings.php later), and it invasively took over all discussion pages, among other headache. Problems like these could easily be addressed before a rollout, but they should be addressed as early as possible. It is notable, however, that the more our users used it, the more they seemed to like it.
What can we do to make the Flow rollout as smooth as starting '''now'''?
,Wil
On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW?
Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment.
But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless.
That also explains the very deliberate development and feedback loop.
-- Marc
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 there have been some pretty strong indications over the years that the current talk page system needs to be improved. However, there's been little discussion at all about whether Flow is that improvement. I have been following the development for quite a while, and it really looks like the system was developed backwards: essential functions for effective discussion that already exist and are used on a daily basis were not included in the initial designs, while the design incorporated plenty of bells and whistles that were considered desirable (although the reasons for desirability weren't necessarily universally held or particularly clear). This has resulted in a huge amount of re-engineering to incorporate (some of the) needed functions , and a lot of downplaying of the feedback given because the feedback has conflicted with the "bells and whistles" of the original design. There is also the fact that it would add another completely different user interface to the editing process, which increases barriers for existing users but even more so for new users.
In other words, the issues with Flow are so deeply rooted in its core design and philosophy that it may not be possible to come up with a product that is actually useful on the projects we have to replace the discussion system we have. It seems that the Flow team has assembled the ingredients to make a chocolate cake with the hope that it will be a suitable replacement for vegetable stew.
Risker/Anne
On 5 September 2014 13:29, Wil Sinclair wllm@wllm.com wrote:
This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle:
- Is the WMF working with the community as closely and substantially
as possible to make sure Flow is ready for primetime?
- Is the community preparing itself for a major change, not only in
interface, but to some degree in wiki-philosophy about how discussions are conducted- not to mention the notion that, while wiki software can do almost anything involving asynchronous online communication, it can't do everything as well as other interfaces?
I think Flow will be particularly challenging. I deployed Liquid Threads on another site. I liked the threaded interface, as did others. But overall it was roundly rejected because it was harder to search (I only found out you have to add the namespace to the searchable namespace in LocalSettings.php later), and it invasively took over all discussion pages, among other headache. Problems like these could easily be addressed before a rollout, but they should be addressed as early as possible. It is notable, however, that the more our users used it, the more they seemed to like it.
What can we do to make the Flow rollout as smooth as starting '''now'''?
,Wil
On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW?
Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment.
But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless.
That also explains the very deliberate development and feedback loop.
-- Marc
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 https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Interesting. What I'm noticing in both this discussion and the discussions around MV is that a lot of us think that the solution has value, but the features are not prioritized well. I don't have much experience with Trello, but I know of lots of other tools (Bugzilla is one, I believe) that can support discussions from the community per feature/bug and have a "voting" feature.
I don't support RfC's on full systems. If we get to this point we've all been doing it wrong for far too long to have an easy fix. But I think that RfC-like discussions on every individual feature make a lot of sense. And I think that one of the biggest steps the WMF can take is to base prioritization of features on such "RfC"'s in a well-defined and well-understood way. IMO, user studies are important, but they'd be better used to '''convince''' the community that something is useful from a perspective that may be very different from a very experienced user's, rather than force features down our throats.
I know that this is already happening to some degree. But is the WMF '''obligated''' to prioritize features based on community feedback?
As a separate question, would we find it easier to do this onwiki, and are there extensions that we can build with the WMF to facilitate such discussions and feature management? Or we cool with the tools we already have?
,Wil
On Fri, Sep 5, 2014 at 10:58 AM, Risker risker.wp@gmail.com wrote:
I think there have been some pretty strong indications over the years that the current talk page system needs to be improved. However, there's been little discussion at all about whether Flow is that improvement. I have been following the development for quite a while, and it really looks like the system was developed backwards: essential functions for effective discussion that already exist and are used on a daily basis were not included in the initial designs, while the design incorporated plenty of bells and whistles that were considered desirable (although the reasons for desirability weren't necessarily universally held or particularly clear). This has resulted in a huge amount of re-engineering to incorporate (some of the) needed functions , and a lot of downplaying of the feedback given because the feedback has conflicted with the "bells and whistles" of the original design. There is also the fact that it would add another completely different user interface to the editing process, which increases barriers for existing users but even more so for new users.
In other words, the issues with Flow are so deeply rooted in its core design and philosophy that it may not be possible to come up with a product that is actually useful on the projects we have to replace the discussion system we have. It seems that the Flow team has assembled the ingredients to make a chocolate cake with the hope that it will be a suitable replacement for vegetable stew.
Risker/Anne
Risker, what do you think might get us all back on track for Flow? Should the WMF consider a reset of the project and proceed only after making specific and enforceable commitments to work with the community? Is a total rewrite in order? Should we go completely tabla rasa on it and revisit whether we need something like this at all?
,Wil
On Fri, Sep 5, 2014 at 10:58 AM, Risker risker.wp@gmail.com wrote:
I think there have been some pretty strong indications over the years that the current talk page system needs to be improved. However, there's been little discussion at all about whether Flow is that improvement. I have been following the development for quite a while, and it really looks like the system was developed backwards: essential functions for effective discussion that already exist and are used on a daily basis were not included in the initial designs, while the design incorporated plenty of bells and whistles that were considered desirable (although the reasons for desirability weren't necessarily universally held or particularly clear). This has resulted in a huge amount of re-engineering to incorporate (some of the) needed functions , and a lot of downplaying of the feedback given because the feedback has conflicted with the "bells and whistles" of the original design. There is also the fact that it would add another completely different user interface to the editing process, which increases barriers for existing users but even more so for new users.
In other words, the issues with Flow are so deeply rooted in its core design and philosophy that it may not be possible to come up with a product that is actually useful on the projects we have to replace the discussion system we have. It seems that the Flow team has assembled the ingredients to make a chocolate cake with the hope that it will be a suitable replacement for vegetable stew.
Risker/Anne
On 5 September 2014 13:29, Wil Sinclair wllm@wllm.com wrote:
This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle:
- Is the WMF working with the community as closely and substantially
as possible to make sure Flow is ready for primetime?
- Is the community preparing itself for a major change, not only in
interface, but to some degree in wiki-philosophy about how discussions are conducted- not to mention the notion that, while wiki software can do almost anything involving asynchronous online communication, it can't do everything as well as other interfaces?
I think Flow will be particularly challenging. I deployed Liquid Threads on another site. I liked the threaded interface, as did others. But overall it was roundly rejected because it was harder to search (I only found out you have to add the namespace to the searchable namespace in LocalSettings.php later), and it invasively took over all discussion pages, among other headache. Problems like these could easily be addressed before a rollout, but they should be addressed as early as possible. It is notable, however, that the more our users used it, the more they seemed to like it.
What can we do to make the Flow rollout as smooth as starting '''now'''?
,Wil
On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW?
Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment.
But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless.
That also explains the very deliberate development and feedback loop.
-- Marc
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 https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-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
Wil, the tl;dr here is "Philosophical beliefs aren't an effective underpinning for good software design. Start over."
It's taken me a while to piece together much from the early discussions about Flow and figure out how we got to where we are now. It's my opinion that the root of the problem is that, much as the WMF wants to move toward being a "software" or "tech" organization, it really doesn't have very much history or experience in the kind of ground-up software design and deployment that is conducive to successful implementation. Tech organizations seeking to redevelop a core function normally start by gathering extensive data on the current system, identifying key functions that must be incorporated into the new system, understanding how the current system is used, what its strengths and weaknesses are, and ensuring that even early iterations will at least include the key functions and strengths from the soon-to-be-deprecated system. This baseline background research was never really done before investing in the development of Flow. Instead, Flow very much comes across as software being designed according to philosophical principles rather than function.
The major deficiencies that have long been identified in the current discussion system (and that can be addressed by technology) are all able to be addressed in MediaWiki software or by extensions. Automatic signatures have been done by bots for years; indenting could be added to the editing function gadget and moved to an extension; much work has already been done on graceful resolution of edit conflicts. The ability to watchlist an individual thread or section of a page is more challenging but, I have been told, still possible.
Several of the features identified as "must-do" have turned out not to quite work out. Automatic signature (something that is currently functional on Flow, but is not customizable) turns out to be more of a challenge when users are widely known by a signature line that doesn't match their username, and there is no method by which users can add an "explanatory" note to their signature such as "formerly known as User:Whatever". The "more efficient" indenting has reduced possible indents to three levels, without exception; even in simple discussions, it's pretty clear that hasn't really worked out as it's often difficult to figure out who is responding to which post. "Rigid predictable technical restrictions on who can edit what" has resulted in inability to remove posts that are obviously unsuitable (there's no "undo" or "revert" function), replaced with a "hide" function that can only be applied by certain users that's practically a red flag for people to look-see what the problem edit is. With broader early discussion, some of these would probably have been fleshed out before getting this far.
At the core is whether or not there is value in developing a "discussion system" that is radically divorced from any other interface used by the system. This is a philosophical question, and doesn't actually have that much to do with technology - and this conversation has never really taken place anywhere but by a bunch of guys who are into making cool software and, often as not, have little interest in the kinds of discussions that normally occur on Wikimedia projects. There has certainly never really been a discussion with the broader community about what would better serve in discussions. More importantly, some of the core assumptions and goals upon which Flow has been built[1] have very little to do with technology at all - plenty of research indicates that new users are driven away by the nature of discussions rather than the technological challenges of participation - and the lack of active broad community consultation means that the development team really doesn't know what's working well, what's problematic, and what kind of efficiencies experienced users are looking for. There's absolutely no basis to believe that Flow is in any way likely "to encourage [more] *meaningful conversations* that support collaboration". (I'd love to see what kind of metrics would be used to assess the meaningfulness of conversations!)
And the other key issue is a complete lack of recognition that the more UIs a new user needs to learn to develop competency, the lower the likelihood that they'll actually be able to develop the necessary skills to become fully functioning members of the editing community. The Wikimedia "family" has largely bought in to the necessity to introduce a WYSIWYG editing interface (that would be VisualEditor), and to recognize that wikitext editing needs to remain in existence as well. Adding a third one whose primary purpose will be to talk about the content being created using the other two is counterintuitive at best.
Risker/Anne
[1] https://www.mediawiki.org/wiki/Flow
On 5 September 2014 21:53, Wil Sinclair wllm@wllm.com wrote:
Risker, what do you think might get us all back on track for Flow? Should the WMF consider a reset of the project and proceed only after making specific and enforceable commitments to work with the community? Is a total rewrite in order? Should we go completely tabla rasa on it and revisit whether we need something like this at all?
,Wil
On Fri, Sep 5, 2014 at 10:58 AM, Risker risker.wp@gmail.com wrote:
I think there have been some pretty strong indications over the years
that
the current talk page system needs to be improved. However, there's been little discussion at all about whether Flow is that improvement. I have been following the development for quite a while, and it really looks
like
the system was developed backwards: essential functions for effective discussion that already exist and are used on a daily basis were not included in the initial designs, while the design incorporated plenty of bells and whistles that were considered desirable (although the reasons
for
desirability weren't necessarily universally held or particularly clear). This has resulted in a huge amount of re-engineering to incorporate (some of the) needed functions , and a lot of downplaying of the feedback given because the feedback has conflicted with the "bells and whistles" of the original design. There is also the fact that it would add another completely different user interface to the editing process, which
increases
barriers for existing users but even more so for new users.
In other words, the issues with Flow are so deeply rooted in its core design and philosophy that it may not be possible to come up with a
product
that is actually useful on the projects we have to replace the discussion system we have. It seems that the Flow team has assembled the
ingredients
to make a chocolate cake with the hope that it will be a suitable replacement for vegetable stew.
Risker/Anne
On 5 September 2014 13:29, Wil Sinclair wllm@wllm.com wrote:
This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle:
- Is the WMF working with the community as closely and substantially
as possible to make sure Flow is ready for primetime?
- Is the community preparing itself for a major change, not only in
interface, but to some degree in wiki-philosophy about how discussions are conducted- not to mention the notion that, while wiki software can do almost anything involving asynchronous online communication, it can't do everything as well as other interfaces?
I think Flow will be particularly challenging. I deployed Liquid Threads on another site. I liked the threaded interface, as did others. But overall it was roundly rejected because it was harder to search (I only found out you have to add the namespace to the searchable namespace in LocalSettings.php later), and it invasively took over all discussion pages, among other headache. Problems like these could easily be addressed before a rollout, but they should be addressed as early as possible. It is notable, however, that the more our users used it, the more they seemed to like it.
What can we do to make the Flow rollout as smooth as starting '''now'''?
,Wil
On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW?
Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment.
But you're correct that this would constitute a replacement rather
than
a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless.
That also explains the very deliberate development and feedback loop.
-- Marc
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 <
https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wi...
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 Fri, Sep 5, 2014 at 10:42 PM, Risker risker.wp@gmail.com wrote:
The major deficiencies that have long been identified in the current discussion system (and that can be addressed by technology) are all able to be addressed in MediaWiki software or by extensions. Automatic signatures have been done by bots for years; indenting could be added to the editing function gadget and moved to an extension; much work has already been done on graceful resolution of edit conflicts. The ability to watchlist an individual thread or section of a page is more challenging but, I have been told, still possible.
Let's just acknowledge that the limitations of what can reasonably be layered onto wikitext-based representation of comments have not been fully explored, rather than jumping to conclusions about what's easy to address and what's hard. As noted separately, I agree it may be worth pushing the boundaries a bit more on this, if only to know exactly where they are, and to achieve short term improvements.
Automatic signature (something that is currently functional on Flow, but is not customizable) turns out to be more of a challenge when users are widely known by a signature line that doesn't match their username,
I've not talked to them about it explicitly, but I'd guess that the PM and the UX folks have a negative aversion against custom signatures because of their free-form nature (including sometimes layout-exploding ones). Perhaps a middle-ground can be found here, with some more sanitization applied to prevent some of the sigs-from-hell occasionally found. Other than that I can't see a good reason to not just show them when they're set, and it's certainly technically trivial to do so.
and there is no method by which users can add an "explanatory" note to their signature such as "formerly known as User:Whatever".
From the point forward that Flow is in wide use, a user rename would
be automatically reflected in old comments if desired, much as it is reflected in old edits. But if signatures were supported, as above, you could still use them for these types of indicators, as well.
The "more efficient" indenting has reduced possible indents to three levels, without exception;
This seems to be the most religious topic when it comes to Flow. The database stores all threading information. It'd be trivial to expand the threading level if that's more popular and usable.
I've heard the argument that this doesn't work on mobile, but we could just set a different threading level on mobile.
I think it's worth experimenting with flat pages (with quoting) for certain purposes, and Danny wants to, but it strikes me as most reasonable to start with something that more closely resembles talk pages as they are now (which is why we did that with LQT originally).
"Rigid predictable technical restrictions on who can edit what" has resulted in inability to remove posts that are obviously unsuitable (there's no "undo" or "revert" function), replaced with a "hide" function that can only be applied by certain users that's practically a red flag for people to look-see what the problem edit is.
The team has pretty strong arguments why they don't want posts to be editable (the gist is, they fear that no other discussion system does this, and it will freak people out -- they see the introduction of a new system as a good opportunity to reset expectations). I personaly am not religious about it; when we built LQT we made posts editable (and made it clear who had edited someone else's posts) to preserve that normal aspect of wiki-style editing. I think we should keep talking about this.
I've not seen it named as a dealbreaker for small scale deployments. The architecture can easily support both models.
At the core is whether or not there is value in developing a "discussion system" that is radically divorced from any other interface used by the system.
That's a legitimate question, although it's not as "radically divorced" as you would think; ultimately it'll use the VisualEditor (probably with a simplified toolbar by default) just like Flow does.
As for the claim that the team never looked at current use cases, having spent hours in rooms with them where they pored over printouts of hundreds of talk pages, analyzed use cases, categorized them, prioritized them, etc., I can assure you there's been a lot more of this kind of thinking than you appreciate. There also have been round tables and other outreach efforts, and a dedicated community liaison from the start. Still, I don't think there's been enough talking to each other -- we're still getting better at doing that, collectively, and trusting in the value of conversation even when there's a lot of noise and a lot of heat.
This is an opportunity for me to remind folks that the cost of heat (accusations, insults, reverts, etc.) is that people withdraw. We (WMF) have to do our part to prevent things from getting heated, but I'd ask folks who notice this kind of thing and who understand why it's harmful to help step in and contribute to a calm, rational, constructive dialog, as well. I can take a lot of heat, as you may have noticed, but a lot of folks just tend to back away when things get personal.
Thanks, Erik
On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller erik@wikimedia.org wrote:
That's a legitimate question, although it's not as "radically divorced" as you would think; ultimately it'll use the VisualEditor (probably with a simplified toolbar by default) just like Flow does.
.. just like article editing, I mean - you'll have a choice between VE/wikitext, probably with a toolbar that's optimized for comments (perhaps advanced tools available when needed).
Moreover, I think the idea that talk pages are actually an intuitive system once you're familiar with editing articles is both unproven and contradicted by all user research into article editing and talk pages. Users discover wikitext incrementally, and they understand it to be "kind of like HTML". They think of it as a document formatting language.
When they first discover talk pages, they have to learn a whole new set of conventions -- the notion of signing and indenting your own comments, the idea that in order to participate in a thread you have to edit it, etc. That is a system divorced from editing, and it's a mental model unlike any other discussion system.
The argument would be more supportable if you could layer a decent UI on top of wikitext-based talk pages, as you suggest. But if you can do that, you'll end up with a UI that introduces many of the same conventions that Flow introduces, just with a hard limitation on some of the additional capabilities and conveniences you can introduce. It may be, as I acknowledged, still worth doing - even as an interim step towards Flow.
Erik
Something that that would be useful is a video demonstration of Flow in action.
I like the goal of VE in principle, and I hear lots of comments to the effect that it is improving over time. MediaViewer seems to be on the road to improvement. I understand where both of those are headed. But I am trying to get a mental picture of Flow from what I've read. A video would be worth a thousand words. If Flow helps us to organize discussions in ways that makes them easier for everyone to follow, that will be good. If Flow disrupts constructive ways of having conversations and is not intuitive, there will be yet another round of power users asking why time and money are being spent on projects that miss the biggest pain points and may cause more pain. I am hoping that Flow will be an improvement, and I think a video demo or mockup of Flow would be helpful to evaluate if Flow's design is likely to produce the intended results.
Pine
On Fri, Sep 5, 2014 at 11:29 PM, Erik Moeller erik@wikimedia.org wrote:
On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller erik@wikimedia.org wrote:
That's a legitimate question, although it's not as "radically divorced" as you would think; ultimately it'll use the VisualEditor (probably with a simplified toolbar by default) just like Flow does.
.. just like article editing, I mean - you'll have a choice between VE/wikitext, probably with a toolbar that's optimized for comments (perhaps advanced tools available when needed).
Moreover, I think the idea that talk pages are actually an intuitive system once you're familiar with editing articles is both unproven and contradicted by all user research into article editing and talk pages. Users discover wikitext incrementally, and they understand it to be "kind of like HTML". They think of it as a document formatting language.
When they first discover talk pages, they have to learn a whole new set of conventions -- the notion of signing and indenting your own comments, the idea that in order to participate in a thread you have to edit it, etc. That is a system divorced from editing, and it's a mental model unlike any other discussion system.
The argument would be more supportable if you could layer a decent UI on top of wikitext-based talk pages, as you suggest. But if you can do that, you'll end up with a UI that introduces many of the same conventions that Flow introduces, just with a hard limitation on some of the additional capabilities and conveniences you can introduce. It may be, as I acknowledged, still worth doing - even as an interim step towards Flow.
Erik
Erik Möller VP of Engineering and Product Development, 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 Fri, Sep 5, 2014 at 11:41 PM, Pine W wiki.pine@gmail.com wrote:
Something that that would be useful is a video demonstration of Flow in action.
That could be handy, Pine. But sometimes you can't demonstrate all benefits yet, because they don't even exist in the implementation yet -- only in the foundations of an architecture. And sometimes you can show the idea of a benefit, but people will look at the current implementation and hate some aspect of it, and fail to imagine a version of it that would be beneficial.
To give an example of the latter, Flow already has the ability to give thread-level notifications of responses. But the first implementation of notifications was very spammy (generated too many notifications), so people who looked at it said "I don't see the benefit! It's just spammy!". Love em or hate em, sites like Facebook spend years tweaking the algorithm for every one of their features (newsfeed, notifications, etc.) to get the best results from their perspective. It takes time to get this right -- and the initial reaction may often be "No, this sucks" because, well, it's not quite right yet.
Fundamentally, I'd ask people to relax a bit regarding Flow. Nobody's planning to push this one out radically. Today we saw some on-wiki drama because a new test page was turned on. For something like the en.wp Teahouse, I'd want the hosts to be fully on-board before converting it over (and the rest of the community to not oppose it). If that's not doable, we can focus on other use cases first. It's early days and this one's a long haul -- just like VE. But we shouldn't shy away from a problem just because it's hard.
Erik
Fundamentally, I'd ask people to relax a bit regarding Flow. Nobody's planning to push this one out radically. Today we saw some on-wiki drama because a new test page was turned on. For something like the en.wp Teahouse, I'd want the hosts to be fully on-board before converting it over (and the rest of the community to not oppose it). If that's not doable, we can focus on other use cases first. It's early days and this one's a long haul -- just like VE. But we shouldn't shy away from a problem just because it's hard.
I think this is one of the points some of us here are trying to make. We *don't* want Flow to be just like VE. We want it to be a good piece of software that is rolled out smoothly.
There are some serious communication problems that I can already see having a toll. Fractured discussions, issues/concerns not captured in workflows, and many members of the community who feel like they haven't been heard out during earlier stages of the project. We have an opportunity to not get all wound around the axle like we have been with MV, and that opportunity should not be thrown away.
Quite frankly, the WMF could do a lot more to improve communications across the community with respect to Flow. Pick one forum and redirect discussions- even this one- to it. Right now there are a few candidates. Make sure all the takeaways from those discussions are captured in workflows; don't let ideas get lost in archives. Choose one place to keep your backlog- bugzilla or trello- and stick with it. You'll need the community's help to see what works for the different roles everyone must play to make software that works well for its users. But the community needs your help in organizing the highly detailed communications with users that is always required to build good software.
It good to hear you say that this is a long haul, because Flow obviously has a ways to go. But that doesn't mean it has to be a death march to the same reception as VE or MV. Let's all be smarter this time. Learning how to communicate better is a great place to start, and I hope the feedback I've given here is helpful. Please let me know if there is anything you can think of that I- or anyone else in the broader community- can do to help you hit this one out of the park.
,Wil
I would suggest aiming for a series of base hits. (: An attempt was made to hit VE out of the park. We know how well that worked.
I think a lot of the work of capturing suggestions is supposed to be done by the project manager and the engineering community liaisons. It would be interesting to have community ideas documented in a single, public, searchable, well-organized location. The project manager and community liaison could be the curators.
It might be good for people who are interested in Flow to attend the Flow IRC office hours, and join in the Flow discussions on the Editor Engagement email list.
Pine
On Sun, Sep 7, 2014 at 12:38 AM, Wil Sinclair wllm@wllm.com wrote:
Fundamentally, I'd ask people to relax a bit regarding Flow. Nobody's planning to push this one out radically. Today we saw some on-wiki drama because a new test page was turned on. For something like the en.wp Teahouse, I'd want the hosts to be fully on-board before converting it over (and the rest of the community to not oppose it). If that's not doable, we can focus on other use cases first. It's early days and this one's a long haul -- just like VE. But we shouldn't shy away from a problem just because it's hard.
I think this is one of the points some of us here are trying to make. We *don't* want Flow to be just like VE. We want it to be a good piece of software that is rolled out smoothly.
There are some serious communication problems that I can already see having a toll. Fractured discussions, issues/concerns not captured in workflows, and many members of the community who feel like they haven't been heard out during earlier stages of the project. We have an opportunity to not get all wound around the axle like we have been with MV, and that opportunity should not be thrown away.
Quite frankly, the WMF could do a lot more to improve communications across the community with respect to Flow. Pick one forum and redirect discussions- even this one- to it. Right now there are a few candidates. Make sure all the takeaways from those discussions are captured in workflows; don't let ideas get lost in archives. Choose one place to keep your backlog- bugzilla or trello- and stick with it. You'll need the community's help to see what works for the different roles everyone must play to make software that works well for its users. But the community needs your help in organizing the highly detailed communications with users that is always required to build good software.
It good to hear you say that this is a long haul, because Flow obviously has a ways to go. But that doesn't mean it has to be a death march to the same reception as VE or MV. Let's all be smarter this time. Learning how to communicate better is a great place to start, and I hope the feedback I've given here is helpful. Please let me know if there is anything you can think of that I- or anyone else in the broader community- can do to help you hit this one out of the park.
,Wil
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
Erik - how confident are you that you're coming up with something that the present users of talk pages - people actually trying to get work done on articles - will love? Not just barely tolerate - what are you bringing us?
- d.
On 06/09/14 06:13, Erik Moeller wrote:
On Fri, Sep 5, 2014 at 10:42 PM, Risker risker.wp@gmail.com wrote:
The major deficiencies that have long been identified in the current discussion system (and that can be addressed by technology) are all able to be addressed in MediaWiki software or by extensions. Automatic signatures have been done by bots for years; indenting could be added to the editing function gadget and moved to an extension; much work has already been done on graceful resolution of edit conflicts. The ability to watchlist an individual thread or section of a page is more challenging but, I have been told, still possible.
Let's just acknowledge that the limitations of what can reasonably be layered onto wikitext-based representation of comments have not been fully explored, rather than jumping to conclusions about what's easy to address and what's hard. As noted separately, I agree it may be worth pushing the boundaries a bit more on this, if only to know exactly where they are, and to achieve short term improvements.
But many of these things have been explored and experimented with. That's just it. We have extensions to create a whole new discussion system already which get some things right and others no so much, like LQT and Comments, and various bots and gadgets that do smaller tasks (auto-signing, indentation, cleanup, etc).
Have the successes and failures of the existing approaches and tools been considered? Are things LQT got right present in Flow?
Automatic signature (something that is currently functional on Flow, but is not customizable) turns out to be more of a challenge when users are widely known by a signature line that doesn't match their username,
I've not talked to them about it explicitly, but I'd guess that the PM and the UX folks have a negative aversion against custom signatures because of their free-form nature (including sometimes layout-exploding ones). Perhaps a middle-ground can be found here, with some more sanitization applied to prevent some of the sigs-from-hell occasionally found. Other than that I can't see a good reason to not just show them when they're set, and it's certainly technically trivial to do so.
Signatures that break the page are currently dealt with by yelling at the user to fix their sig and then blocking them if need be. I dunno how a structured talkpage would necessarily change that, though having the signatures automatically tidied might be useful in general, as it should at least help prevent unclosed tags. Beyond that what they allow really depends on the project, but any structured formatting with sensible padding should work fine no matter what they do (I mean, I've never seen any issues with that with LQT).
and there is no method by which users can add an "explanatory" note to their signature such as "formerly known as User:Whatever".
From the point forward that Flow is in wide use, a user rename would be automatically reflected in old comments if desired, much as it is reflected in old edits. But if signatures were supported, as above, you could still use them for these types of indicators, as well.
The "more efficient" indenting has reduced possible indents to three levels, without exception;
This seems to be the most religious topic when it comes to Flow. The database stores all threading information. It'd be trivial to expand the threading level if that's more popular and usable.
How is this religious? Something is needed to show progression, and lacking anything else, threading has already been proven to work. Just chopping it off has been shown time and again not to (you see it particularly often on blog and news comments).
I've heard the argument that this doesn't work on mobile, but we could just set a different threading level on mobile.
I think it's worth experimenting with flat pages (with quoting) for certain purposes, and Danny wants to, but it strikes me as most reasonable to start with something that more closely resembles talk pages as they are now (which is why we did that with LQT originally).
Formatting the pages as flat with just ids and links to what the things are replying to could be an interesting option experiment with, especially when you don't have a lot of space. Like boards. Be like 4chan! Everyone loves 4chan.
"Rigid predictable technical restrictions on who can edit what" has resulted in inability to remove posts that are obviously unsuitable (there's no "undo" or "revert" function), replaced with a "hide" function that can only be applied by certain users that's practically a red flag for people to look-see what the problem edit is.
The team has pretty strong arguments why they don't want posts to be editable (the gist is, they fear that no other discussion system does this, and it will freak people out -- they see the introduction of a new system as a good opportunity to reset expectations). I personaly am not religious about it; when we built LQT we made posts editable (and made it clear who had edited someone else's posts) to preserve that normal aspect of wiki-style editing. I think we should keep talking about this.
Why in the world would posts not be editable? I've never used a platform where discussion was important in which users couldn't at least edit their own posts (along with mods) where the lack of such wasn't often complained about (for instance bugzilla and gerrit don't allow it; moodle and tumblr do). The whole idea of wikis is that they are more open than most platforms, and what that means in practice is that we trust users to act as mods too. The power structure is generally much less rigid where security isn't a major concern, and social norms take its place. And this is true across many, many mw-based projects I've used and/or contributed to.
I've not seen it named as a dealbreaker for small scale deployments. The architecture can easily support both models.
At the core is whether or not there is value in developing a "discussion system" that is radically divorced from any other interface used by the system.
That's a legitimate question, although it's not as "radically divorced" as you would think; ultimately it'll use the VisualEditor (probably with a simplified toolbar by default) just like Flow does.
As for the claim that the team never looked at current use cases, having spent hours in rooms with them where they pored over printouts of hundreds of talk pages, analyzed use cases, categorized them, prioritized them, etc., I can assure you there's been a lot more of this kind of thinking than you appreciate. There also have been round tables and other outreach efforts, and a dedicated community liaison from the start. Still, I don't think there's been enough talking to each other -- we're still getting better at doing that, collectively, and trusting in the value of conversation even when there's a lot of noise and a lot of heat.
So they did look and this is what they came up with? Interesting.
This is an opportunity for me to remind folks that the cost of heat (accusations, insults, reverts, etc.) is that people withdraw. We (WMF) have to do our part to prevent things from getting heated, but I'd ask folks who notice this kind of thing and who understand why it's harmful to help step in and contribute to a calm, rational, constructive dialog, as well. I can take a lot of heat, as you may have noticed, but a lot of folks just tend to back away when things get personal.
Thanks, Erik
On Sat, Sep 6, 2014 at 12:23 AM, Isarra Yos zhorishna@gmail.com wrote:
Have the successes and failures of the existing approaches and tools been considered? Are things LQT got right present in Flow?
Some, yes (remember Andrew and Brandon have worked on both LQT and Flow) -- in other cases the team deliberately made a different call, and they may have gotten it wrong, or not. Let's reason it through.
Flow has LQT-style headers, for example, and thread-level summaries, both with a much nicer UX than LQT, but adopting some of the same principles.
Signatures that break the page are currently dealt with by yelling at the user to fix their sig and then blocking them if need be. I dunno how a structured talkpage would necessarily change that, though having the signatures automatically tidied might be useful in general, as it should at least help prevent unclosed tags.
Sure, some leeway (and some testing/sanitization) makes sense to me to see what works.
Formatting the pages as flat with just ids and links to what the things are replying to could be an interesting option experiment with, especially when you don't have a lot of space. Like boards. Be like 4chan! Everyone loves 4chan.
*cough*
Why in the world would posts not be editable? I've never used a platform where discussion was important in which users couldn't at least edit their own posts (along with mods) where the lack of such wasn't often complained about (for instance bugzilla and gerrit don't allow it; moodle and tumblr do).
Sorry, I should have been clearer. By default, Flow lets you edit your own comments, and lets admins edit all comments, just like typical forum conventions. It just doesn't let everyone edit everything.
On 06/09/14 07:41, Erik Moeller wrote:
On Sat, Sep 6, 2014 at 12:23 AM, Isarra Yos zhorishna@gmail.com wrote:
Why in the world would posts not be editable? I've never used a platform where discussion was important in which users couldn't at least edit their own posts (along with mods) where the lack of such wasn't often complained about (for instance bugzilla and gerrit don't allow it; moodle and tumblr do).
Sorry, I should have been clearer. By default, Flow lets you edit your own comments, and lets admins edit all comments, just like typical forum conventions. It just doesn't let everyone edit everything.
But that's not how wikis work. On other platforms that do support such editing at all, users edit their own articles, and their own comments, with only moderators trusted to change them. But on wikis, the users are also the moderators. This applies to content and comments, and admins are only required where things can become sensitive (where concerns of privacy, site stability, or simply dangerous tools in terms of vandalism come into play). Why the sudden divergence that only admins can be mods here? Discussions aren't sensitive.
This sort of thing is a large part of why some of us are so skeptical of Flow currently - if the designers do not even understand the basic principles behind a wiki, how can what is developed possibly suit our needs? The thing is, they - you - need to start really listening, and not just arguing (or not responding at all), because otherwise things are just going to get messier and messier.
-I
On 09/06/2014 12:34 PM, Isarra Yos wrote:
if the designers do not even understand the basic principles behind a wiki, how can what is developed possibly suit our needs?
You're starting from the presumption that, for some unexplained reason, collaborative discussion benefits from being a wiki (as opposed to, you know, the actual content).
Very many people, myself included, believe that a wiki page is an *atrocious* medium for discussion. It obfuscates who is talking to whom under layers of markup, can make discussion flow (see what I did here?) impossible to divine unless you are an old hand, and is otherwise nearly-impossible for most newbies to partake in.
Hell, I've been around for over ten years and on large volume discussions (you know, the ones we *want* lots of participation in), commenting is a pain at best and I /still/ end up having to occasionally have to peruse diffs just to figure out who said what in which order.
I've yet to find a rational motivation for expressing desire for that horrid mess other than "it keeps the newbies away". And yes, that rationale *has* been offered. More than once. In so many words.
Sadly, there *are* people who get offended that the vast unwashed masses could start contributing to *their* project without having gone through a painful, demanding rite of passage. Truth is, most people of the world don't have the time for that, or if they do, (perfectly reasonably) believe that you shouldn't have to pay to volunteer to help.
-- Marc
On 06/09/14 17:06, Marc A. Pelletier wrote:
On 09/06/2014 12:34 PM, Isarra Yos wrote:
if the designers do not even understand the basic principles behind a wiki, how can what is developed possibly suit our needs?
You're starting from the presumption that, for some unexplained reason, collaborative discussion benefits from being a wiki (as opposed to, you know, the actual content).
Very many people, myself included, believe that a wiki page is an *atrocious* medium for discussion. It obfuscates who is talking to whom under layers of markup, can make discussion flow (see what I did here?) impossible to divine unless you are an old hand, and is otherwise nearly-impossible for most newbies to partake in.
Hell, I've been around for over ten years and on large volume discussions (you know, the ones we *want* lots of participation in), commenting is a pain at best and I /still/ end up having to occasionally have to peruse diffs just to figure out who said what in which order.
I've yet to find a rational motivation for expressing desire for that horrid mess other than "it keeps the newbies away". And yes, that rationale *has* been offered. More than once. In so many words.
Sadly, there *are* people who get offended that the vast unwashed masses could start contributing to *their* project without having gone through a painful, demanding rite of passage. Truth is, most people of the world don't have the time for that, or if they do, (perfectly reasonably) believe that you shouldn't have to pay to volunteer to help.
-- Marc
Where did I say wiki pages are a good discussion medium?
-I
Marc,
Wanting to "keep the newbies away" is hardly a common reason for people's opposition to Flow. Someone might've said such a thing, but to paint that as the reason for opposition for even a significant minority is totally inaccurate.
You can, of course, say that all the other reasons given are irrational, though I wouldn't agree. But dismissing them by setting up a (rather ridiculous) straw man is not helpful.
On Sat, Sep 6, 2014 at 11:06 AM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/06/2014 12:34 PM, Isarra Yos wrote:
if the designers do not even understand the basic principles behind a wiki, how can what is developed possibly suit our needs?
You're starting from the presumption that, for some unexplained reason, collaborative discussion benefits from being a wiki (as opposed to, you know, the actual content).
Very many people, myself included, believe that a wiki page is an *atrocious* medium for discussion. It obfuscates who is talking to whom under layers of markup, can make discussion flow (see what I did here?) impossible to divine unless you are an old hand, and is otherwise nearly-impossible for most newbies to partake in.
Hell, I've been around for over ten years and on large volume discussions (you know, the ones we *want* lots of participation in), commenting is a pain at best and I /still/ end up having to occasionally have to peruse diffs just to figure out who said what in which order.
I've yet to find a rational motivation for expressing desire for that horrid mess other than "it keeps the newbies away". And yes, that rationale *has* been offered. More than once. In so many words.
Sadly, there *are* people who get offended that the vast unwashed masses could start contributing to *their* project without having gone through a painful, demanding rite of passage. Truth is, most people of the world don't have the time for that, or if they do, (perfectly reasonably) believe that you shouldn't have to pay to volunteer to help.
-- Marc
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 09/06/2014 01:12 PM, Todd Allen wrote:
But dismissing them by setting up a (rather ridiculous) straw man is not helpful.
I *wish* it was a strawman. How else would you qualify:
"And sadly we have enough users around who try to contribute content without having time to go through "the rite of passage", and we have to spend way too much time reverting and rewriting their contribution to make it appropriate for an encyclopedia."
It's more than a little sad to not even have had to /look/ for that comment, it was offered in response to Gerard not even five minutes ago.
-- Marc
On 06.09.2014 19:06, Marc A. Pelletier wrote:
On 09/06/2014 12:34 PM, Isarra Yos wrote:
Sadly, there *are* people who get offended that the vast unwashed masses could start contributing to *their* project without having gone through a painful, demanding rite of passage. Truth is, most people of the world don't have the time for that, or if they do, (perfectly reasonably) believe that you shouldn't have to pay to volunteer to help.
-- Marc
Marc, with all my due respect, this statement would be more convincing if spelled out by someone with more than 13 edits in the article space combined in 2013 and 2014.
Cheers Yaroslav
Hoi, The subject is discussion / talk space not article space editing.. Yaroslav please stay on topic..Surely Marc has more than 13 edits in all kinds of discussion on multiple wikis. Thanks, GerardM
On 6 September 2014 19:14, Yaroslav M. Blanter putevod@mccme.ru wrote:
On 06.09.2014 19:06, Marc A. Pelletier wrote:
On 09/06/2014 12:34 PM, Isarra Yos wrote:
Sadly, there *are* people who get offended that the vast unwashed masses
could start contributing to *their* project without having gone through a painful, demanding rite of passage. Truth is, most people of the world don't have the time for that, or if they do, (perfectly reasonably) believe that you shouldn't have to pay to volunteer to help.
-- Marc
Marc, with all my due respect, this statement would be more convincing if spelled out by someone with more than 13 edits in the article space combined in 2013 and 2014.
Cheers Yaroslav
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 06.09.2014 19:18, Gerard Meijssen wrote:
Hoi, The subject is discussion / talk space not article space editing.. Yaroslav please stay on topic..Surely Marc has more than 13 edits in all kinds of discussion on multiple wikis. Thanks, GerardM
On 6 September 2014 19:14, Yaroslav M. Blanter putevod@mccme.ru wrote:
On 06.09.2014 19:06, Marc A. Pelletier wrote:
Sadly, there *are* people who get offended that the vast unwashed masses
could start contributing to *their* project without having gone through a painful, demanding rite of passage. Truth is, most people of the world don't have the time for that, or if they do, (perfectly reasonably) believe that you shouldn't have to pay to volunteer to help.
-- Marc
Marc, with all my due respect, this statement would be more convincing if spelled out by someone with more than 13 edits in the article space combined in 2013 and 2014.
Cheers Yaroslav
Sure. However, contributing to *our* project, meaning (I guess) in this case the English Wikipedia, is most and foremost contributing content. And sadly we have enough users around who try to contribute content without having time to go through "the rite of passage", and we have to spend way too much time reverting and rewriting their contribution to make it appropriate for an encyclopedia.
I agree though that this is off-topic in this thread.
Cheers Yaroslav
On 06/09/2014, Isarra Yos zhorishna@gmail.com wrote:
Be like 4chan! Everyone loves 4chan.
No.
This is so wrong it hurts.
Fae
I'm not going to reply in-line here, because I think there's been an undoubtedly unintentional missing of the point here. Instead I will tell a story about a friend of mine.
Some years ago, when her children were 3 and 4, their family had a lovely traditional Christmas Day, but something felt like it was "missing". She told her husband about a tradition in her own family, where she and her siblings had (since they were very young children) always bought their mother a Terry's Chocolate Orange for Christmas - no matter what else her mom got, that was considered the one "essential" Christmas gift under the tree. Mom would glow with joy when she unwrapped it, and her most heartfelt thanks was for this specific present. Some time later in the day, she'd smack it open and everyone would get a piece. My friend thought it would be wonderful to start a similar tradition in her own young family.
Her husband remembered this story in the weeks leading up to the next Christmas. He plotted with the children, now 4 and 5; he researched the "best" types of similar treats; and ultimately he "helped" the children obtain a chocolate orange made of the finest Swiss chocolate, filled with Grand Marnier liqueur, presented in an elegant marquetry box. Everyone was surprised when she burst into tears instead of smiles, and spent the whole day snapping at people and generally being a grouch. Finally her husband confronted her and insisted she explain her behaviour.
What happened, of course, was that despite his best efforts, he'd missed the real purpose of the chocolate orange. He thought it was symbolic of the esteem in which the matriarch was held. Really, it was about the familial sharing of a special treat; the joy that the sharing brought to both the recipient and the presenters. But she couldn't share liqueur-filled chocolate with her children, and could barely bring herself to smack open the beautifully designed and presented chocolate. In other words, even though the gift looked brilliant on paper, it missed the point.
I think the design of Flow is much like the liqueur-filled chocolates. It's missed the point of a discussion space on Wikimedia projects. All the use cases in the world, no matter how carefully researched and accounted for, will help you build a discussion system to effectively replace a discussion system if you don't understand that the one overriding, incontrovertible feature of the current system is that it is a page that acts just like all the other wiki pages, with all the same functions, and anyone who can work on one wiki-page can work on any of them. In other words, you're building something that is explicitly different from wiki-pages - but the expectation of the majority of the people who will use these pages is that they work exactly like any other wiki-page.
This is what I mean when I say that you've not really understood how wiki-discussion functions, and you've created the "bells and whistles" without demonstrating an understanding of what the real, core functions of these pages are. The priority in design should focus on being able to produce identical results for basic wiki-editing and page management: we move pages, we protect them, we undo and revert edits, we fix typos and correct URLS and links in each other's posts, we quote each other and copy/paste, we modify each other's words when collaborating on the wording of a complex section of an article, we get rid of trolling, we delete and sometimes suppress personal attacks, we hat and archive individual discussions. Whether or not a post gets auto-signed is a "frill" compared to those basic functions, and it is inevitable that the deprioritization of "the basics" will result in people not really caring much about the frills (no matter how well they are executed) and focusing instead on what the new "system" doesn't do. This is the real parallel between Flow and Visual Editor - focusing on the "difference" between the new product and that it was intended to replace, instead of ensuring that things that had to be similar or identical were considered the first step of design.
Risker/Anne
On 6 September 2014 02:13, Erik Moeller erik@wikimedia.org wrote:
On Fri, Sep 5, 2014 at 10:42 PM, Risker risker.wp@gmail.com wrote:
The major deficiencies that have long been identified in the current discussion system (and that can be addressed by technology) are all able
to
be addressed in MediaWiki software or by extensions. Automatic signatures have been done by bots for years; indenting could be added to the editing function gadget and moved to an extension; much work has already been
done
on graceful resolution of edit conflicts. The ability to watchlist an individual thread or section of a page is more challenging but, I have
been
told, still possible.
Let's just acknowledge that the limitations of what can reasonably be layered onto wikitext-based representation of comments have not been fully explored, rather than jumping to conclusions about what's easy to address and what's hard. As noted separately, I agree it may be worth pushing the boundaries a bit more on this, if only to know exactly where they are, and to achieve short term improvements.
Automatic signature (something that is currently functional on Flow, but is not customizable) turns out to be more of a challenge when users are widely known by a signature line that doesn't match their username,
I've not talked to them about it explicitly, but I'd guess that the PM and the UX folks have a negative aversion against custom signatures because of their free-form nature (including sometimes layout-exploding ones). Perhaps a middle-ground can be found here, with some more sanitization applied to prevent some of the sigs-from-hell occasionally found. Other than that I can't see a good reason to not just show them when they're set, and it's certainly technically trivial to do so.
and there is no method by which users can add an "explanatory" note to their signature such as "formerly known as User:Whatever".
From the point forward that Flow is in wide use, a user rename would be automatically reflected in old comments if desired, much as it is reflected in old edits. But if signatures were supported, as above, you could still use them for these types of indicators, as well.
The "more efficient" indenting has reduced possible indents to three levels, without exception;
This seems to be the most religious topic when it comes to Flow. The database stores all threading information. It'd be trivial to expand the threading level if that's more popular and usable.
I've heard the argument that this doesn't work on mobile, but we could just set a different threading level on mobile.
I think it's worth experimenting with flat pages (with quoting) for certain purposes, and Danny wants to, but it strikes me as most reasonable to start with something that more closely resembles talk pages as they are now (which is why we did that with LQT originally).
"Rigid predictable technical restrictions on who can edit what" has resulted in inability to remove posts that are obviously unsuitable (there's no "undo" or "revert" function), replaced with a "hide" function that can only be applied by certain users that's practically a red flag for people to look-see what
the
problem edit is.
The team has pretty strong arguments why they don't want posts to be editable (the gist is, they fear that no other discussion system does this, and it will freak people out -- they see the introduction of a new system as a good opportunity to reset expectations). I personaly am not religious about it; when we built LQT we made posts editable (and made it clear who had edited someone else's posts) to preserve that normal aspect of wiki-style editing. I think we should keep talking about this.
I've not seen it named as a dealbreaker for small scale deployments. The architecture can easily support both models.
At the core is whether or not there is value in developing a "discussion system" that is radically divorced from any other interface used by the system.
That's a legitimate question, although it's not as "radically divorced" as you would think; ultimately it'll use the VisualEditor (probably with a simplified toolbar by default) just like Flow does.
As for the claim that the team never looked at current use cases, having spent hours in rooms with them where they pored over printouts of hundreds of talk pages, analyzed use cases, categorized them, prioritized them, etc., I can assure you there's been a lot more of this kind of thinking than you appreciate. There also have been round tables and other outreach efforts, and a dedicated community liaison from the start. Still, I don't think there's been enough talking to each other -- we're still getting better at doing that, collectively, and trusting in the value of conversation even when there's a lot of noise and a lot of heat.
This is an opportunity for me to remind folks that the cost of heat (accusations, insults, reverts, etc.) is that people withdraw. We (WMF) have to do our part to prevent things from getting heated, but I'd ask folks who notice this kind of thing and who understand why it's harmful to help step in and contribute to a calm, rational, constructive dialog, as well. I can take a lot of heat, as you may have noticed, but a lot of folks just tend to back away when things get personal.
Thanks, Erik
-- Erik Möller VP of Engineering and Product Development, 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
Hoi, I like your story and I understand the sentiment. For me the story is about the kind of functionality that we may or may not need in Flow. The story is not about retaining what went before.. Mark my words, I cannot wait for the old talk system to go.
As I understand the current situation, Flow is gaining in functionality and it is being used in all kinds of settings. As time goes by, it becomes feature rich and increasingly versatile. I am sure the husband "learned" from the first time an egg was presented to his wife. I am sure they shared fond memories of this moment of embarrassment. Life is short and learning how to improve your ways makes life more pleasant.
The lessons of the egg are for all of us. Do not single out anyone and do not think any of us is beyond the need of learning from past mistakes. Thanks, GerardM
On 7 September 2014 03:17, Risker risker.wp@gmail.com wrote:
I'm not going to reply in-line here, because I think there's been an undoubtedly unintentional missing of the point here. Instead I will tell a story about a friend of mine.
Some years ago, when her children were 3 and 4, their family had a lovely traditional Christmas Day, but something felt like it was "missing". She told her husband about a tradition in her own family, where she and her siblings had (since they were very young children) always bought their mother a Terry's Chocolate Orange for Christmas - no matter what else her mom got, that was considered the one "essential" Christmas gift under the tree. Mom would glow with joy when she unwrapped it, and her most heartfelt thanks was for this specific present. Some time later in the day, she'd smack it open and everyone would get a piece. My friend thought it would be wonderful to start a similar tradition in her own young family.
Her husband remembered this story in the weeks leading up to the next Christmas. He plotted with the children, now 4 and 5; he researched the "best" types of similar treats; and ultimately he "helped" the children obtain a chocolate orange made of the finest Swiss chocolate, filled with Grand Marnier liqueur, presented in an elegant marquetry box. Everyone was surprised when she burst into tears instead of smiles, and spent the whole day snapping at people and generally being a grouch. Finally her husband confronted her and insisted she explain her behaviour.
What happened, of course, was that despite his best efforts, he'd missed the real purpose of the chocolate orange. He thought it was symbolic of the esteem in which the matriarch was held. Really, it was about the familial sharing of a special treat; the joy that the sharing brought to both the recipient and the presenters. But she couldn't share liqueur-filled chocolate with her children, and could barely bring herself to smack open the beautifully designed and presented chocolate. In other words, even though the gift looked brilliant on paper, it missed the point.
I think the design of Flow is much like the liqueur-filled chocolates. It's missed the point of a discussion space on Wikimedia projects. All the use cases in the world, no matter how carefully researched and accounted for, will help you build a discussion system to effectively replace a discussion system if you don't understand that the one overriding, incontrovertible feature of the current system is that it is a page that acts just like all the other wiki pages, with all the same functions, and anyone who can work on one wiki-page can work on any of them. In other words, you're building something that is explicitly different from wiki-pages - but the expectation of the majority of the people who will use these pages is that they work exactly like any other wiki-page.
This is what I mean when I say that you've not really understood how wiki-discussion functions, and you've created the "bells and whistles" without demonstrating an understanding of what the real, core functions of these pages are. The priority in design should focus on being able to produce identical results for basic wiki-editing and page management: we move pages, we protect them, we undo and revert edits, we fix typos and correct URLS and links in each other's posts, we quote each other and copy/paste, we modify each other's words when collaborating on the wording of a complex section of an article, we get rid of trolling, we delete and sometimes suppress personal attacks, we hat and archive individual discussions. Whether or not a post gets auto-signed is a "frill" compared to those basic functions, and it is inevitable that the deprioritization of "the basics" will result in people not really caring much about the frills (no matter how well they are executed) and focusing instead on what the new "system" doesn't do. This is the real parallel between Flow and Visual Editor - focusing on the "difference" between the new product and that it was intended to replace, instead of ensuring that things that had to be similar or identical were considered the first step of design.
Risker/Anne
On 6 September 2014 02:13, Erik Moeller erik@wikimedia.org wrote:
On Fri, Sep 5, 2014 at 10:42 PM, Risker risker.wp@gmail.com wrote:
The major deficiencies that have long been identified in the current discussion system (and that can be addressed by technology) are all
able
to
be addressed in MediaWiki software or by extensions. Automatic
signatures
have been done by bots for years; indenting could be added to the
editing
function gadget and moved to an extension; much work has already been
done
on graceful resolution of edit conflicts. The ability to watchlist an individual thread or section of a page is more challenging but, I have
been
told, still possible.
Let's just acknowledge that the limitations of what can reasonably be layered onto wikitext-based representation of comments have not been fully explored, rather than jumping to conclusions about what's easy to address and what's hard. As noted separately, I agree it may be worth pushing the boundaries a bit more on this, if only to know exactly where they are, and to achieve short term improvements.
Automatic signature (something that is currently functional on Flow, but is not customizable) turns out to be more of a challenge when users are widely known by a signature line that doesn't match their username,
I've not talked to them about it explicitly, but I'd guess that the PM and the UX folks have a negative aversion against custom signatures because of their free-form nature (including sometimes layout-exploding ones). Perhaps a middle-ground can be found here, with some more sanitization applied to prevent some of the sigs-from-hell occasionally found. Other than that I can't see a good reason to not just show them when they're set, and it's certainly technically trivial to do so.
and there is no method by which users can add an "explanatory" note to their signature such as "formerly known as User:Whatever".
From the point forward that Flow is in wide use, a user rename would be automatically reflected in old comments if desired, much as it is reflected in old edits. But if signatures were supported, as above, you could still use them for these types of indicators, as well.
The "more efficient" indenting has reduced possible indents to three levels, without exception;
This seems to be the most religious topic when it comes to Flow. The database stores all threading information. It'd be trivial to expand the threading level if that's more popular and usable.
I've heard the argument that this doesn't work on mobile, but we could just set a different threading level on mobile.
I think it's worth experimenting with flat pages (with quoting) for certain purposes, and Danny wants to, but it strikes me as most reasonable to start with something that more closely resembles talk pages as they are now (which is why we did that with LQT originally).
"Rigid predictable technical restrictions on who can edit what" has resulted in inability to remove posts that are obviously unsuitable (there's no "undo" or "revert" function), replaced with a "hide" function that can only be applied by certain users that's practically a red flag for people to look-see what
the
problem edit is.
The team has pretty strong arguments why they don't want posts to be editable (the gist is, they fear that no other discussion system does this, and it will freak people out -- they see the introduction of a new system as a good opportunity to reset expectations). I personaly am not religious about it; when we built LQT we made posts editable (and made it clear who had edited someone else's posts) to preserve that normal aspect of wiki-style editing. I think we should keep talking about this.
I've not seen it named as a dealbreaker for small scale deployments. The architecture can easily support both models.
At the core is whether or not there is value in developing a
"discussion
system" that is radically divorced from any other interface used by the system.
That's a legitimate question, although it's not as "radically divorced" as you would think; ultimately it'll use the VisualEditor (probably with a simplified toolbar by default) just like Flow does.
As for the claim that the team never looked at current use cases, having spent hours in rooms with them where they pored over printouts of hundreds of talk pages, analyzed use cases, categorized them, prioritized them, etc., I can assure you there's been a lot more of this kind of thinking than you appreciate. There also have been round tables and other outreach efforts, and a dedicated community liaison from the start. Still, I don't think there's been enough talking to each other -- we're still getting better at doing that, collectively, and trusting in the value of conversation even when there's a lot of noise and a lot of heat.
This is an opportunity for me to remind folks that the cost of heat (accusations, insults, reverts, etc.) is that people withdraw. We (WMF) have to do our part to prevent things from getting heated, but I'd ask folks who notice this kind of thing and who understand why it's harmful to help step in and contribute to a calm, rational, constructive dialog, as well. I can take a lot of heat, as you may have noticed, but a lot of folks just tend to back away when things get personal.
Thanks, Erik
-- Erik Möller VP of Engineering and Product Development, 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
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
2014-09-07 4:17 GMT+03:00 Risker risker.wp@gmail.com:
I think the design of Flow is much like the liqueur-filled chocolates. It's missed the point of a discussion space on Wikimedia projects. All
the
use cases in the world, no matter how carefully researched and accounted for, will help you build a discussion system to effectively replace a discussion system if you don't understand that the one overriding, incontrovertible feature of the current system is that it is a page that acts just like all the other wiki pages, with all the same functions, and anyone who can work on one wiki-page can work on any of them.
I see your point, but the fact is that the current system is NOT a page that acts just like all the other wiki pages.
Talk pages use categories differently. Article talk pages, for better or worse, don't have interlanguage links. Talk pages use : for indentation a lot; articles rarely use this piece of syntax. Talk pages can use templates the same way as articles, but the actual templates used on them are different. Long talk pages are archived; articles aren't. Talk pages have signatures; articles, for better or worse, don't. Talk pages rarely have images.
So yes, the wiki syntax is the same, but the practice of its use is fundamentally different. And voila - the wiki syntax in Flow works much the same way as elsewhere - links, templates, etc. The plan is to use the same VisualEditor as for articles in the future. What Flow replaces is the crutches built to force wiki pages into being discussion forums - "talkback", indentation, archive templates and bots, the infinite edit conflicts, etc.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
On Sat, Sep 6, 2014 at 8:13 AM, Erik Moeller erik@wikimedia.org wrote:
The team has pretty strong arguments why they don't want posts to be editable (the gist is, they fear that no other discussion system does this, and it will freak people out -- they see the introduction of a new system as a good opportunity to reset expectations).
I would argue that the best and most successful examples of knowledge production oriented discussion systems allow the editing of posts by others. Quora has that feature. Stackoverflow has that feature. The edit might be sent through a review queue depending on your reputation, but from the user's point of view that's not a big difference, and the bar is pretty low - Stackoverflow allows direct editing from 2000 reputation points, while access to the various queues (which is the closest equivalent to being a Wikipedia admin) comes after 10,000 points. (An active user can easily earn 100 or more points a week, so 2000 points mean a few months of using the site.)
On Sat, Sep 6, 2014 at 3:29 AM, Wil Sinclair wllm@wllm.com wrote:
This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle:
- Is the WMF working with the community as closely and substantially
as possible to make sure Flow is ready for primetime?
...
What can we do to make the Flow rollout as smooth as starting '''now'''?
IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis.
Risker's assessment of the design problems is spot on. As such, a typical WMF-style big bang deploy of Flow is going to be the most almighty bang the WMF has ever seen. And the community is rightly worried that 2015 is going to be the year that WMF forces Flow onto the projects using its typical deploy methodology.
Start development of a rollout plan, and gain consent from the communities on that rollout plan.
After rollout on MediaWiki has stablised, Meta-Wiki should be high on the deploy list, as should any wiki which has LQT enabled by community request. Until discussion-focused wikis, such as Meta, universally *likes* Flow, trialling it or rolling it out onto any 'work'/content-focused wiki without community consent is silly. Until it is satisfactorily deployed onto at least one non-English language content project, it shouldnt be deployed onto English Wikipedia, as it is safe to assume that the design will be too English Wikipedia specific, and will fail badly on non-English projects, becoming another WMF tool which looks nice on English Wikipedia but other projects cant have it because it is designed wrong.
Allow project level opt-out of the Flow rollout plan. Focus on the projects that want it, and find/employ community advocates with the necessary language skills for the projects at the top of the rollout plan. They need to start work *now*. They need to document existing project workflows, talking with bot operators and site admins especially when developing a migration plan. Bot and gadget software will need to be re-engineered *before* the deploy.
-- John Vandenberg
On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis.
This is rank hyperbole.
The MediaWiki deployment train delivers new software to all projects every week. One stage is to non-Wikipedia projects, which actually get new software *first.* Then in a second stage is for all Wikipedias simultaneously. So the default behavior for rollouts, if all you do is merge your code and wait, is that English Wikipedia gets basically no special treatment..[1]
Now, for larger feature rollouts like VisualEditor or MediaViewer, the testing stage and eventual launch set their own special schedule. We have used English Wikipedia as a testing ground a lot in the past, which is natural when you consider a variety of factors.[2] That doesn't mean we haven't worked hard to test things out with non-English projects. Some examples:
-- MediaViewer spent a long time being tested outside English Wikipedia before it ever touched that project. It started with pilots in non-English Wikipedias and English Wikivoyage.[3] -- Flow is currently soliciting editors on non-English projects to test it out voluntarily on a sub-set of pages. Any projects that want to help shape the future of this software should pick a discussion space they want to use for testing and speak up. -- My team (Growth) has begun waiting for translations of experimental interfaces, so we can A/B test in many languages simultaneously. We're about to do this again in this month, by testing task recommendations in 12 languages right from the start.[4] We've done with other projects as well, like A/B testing changes aimed at anonymous editors in four languages. -- The Content Translation project is starting with Spanish and Catalan Wikipedias.[5]
After we get past the testing stage, none of this erases the fact that English Wikipedia is still the largest project by far, and is a major problem spot to be dealt with regarding issues related to new editor acquisition and retention. The data clearly suggests that it's a project we should be focusing on if we want to fix these problems, but we're certainly not ignoring others.
1). wikitech.wikimedia.org/view/Deployments 2). All technical staff and community contributors share English as their working language. Software gets built in English first obviously, so we don't have to wait on translations as a blocker for deployment. English Wikipedia is also our largest project, so we can get larger randomized samples during A/B tests. Making A/B tests shorter while also retaining accuracy is good. 3). https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan 4). https://meta.wikimedia.org/wiki/Research:Task_recommendations/Experiment_one 5). https://www.mediawiki.org/wiki/Content_translation/Roadmap
FWIW, ironically the tangled discussions about MediaViewer across multiple pages have made me think that having a more organized way to read discussions would be a good idea. My understanding is that this is one of Flow's objectives. If Flow can achieve this in a way that is helpful and non-disruptive then I think Flow may save power users time because we may be able to follow multi-page discussions easily. I would appreciate it if Flow helped with that. Of course, the design, implementation and testing need to be done carefully, and I hope there is heavy community involvement in reviewing Flow long before it gets sent to the largest and most sophisticated wikis.
Pine
On Fri, Sep 5, 2014 at 4:07 PM, Steven Walling steven.walling@gmail.com wrote:
On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis.
This is rank hyperbole.
The MediaWiki deployment train delivers new software to all projects every week. One stage is to non-Wikipedia projects, which actually get new software *first.* Then in a second stage is for all Wikipedias simultaneously. So the default behavior for rollouts, if all you do is merge your code and wait, is that English Wikipedia gets basically no special treatment..[1]
Now, for larger feature rollouts like VisualEditor or MediaViewer, the testing stage and eventual launch set their own special schedule. We have used English Wikipedia as a testing ground a lot in the past, which is natural when you consider a variety of factors.[2] That doesn't mean we haven't worked hard to test things out with non-English projects. Some examples:
-- MediaViewer spent a long time being tested outside English Wikipedia before it ever touched that project. It started with pilots in non-English Wikipedias and English Wikivoyage.[3] -- Flow is currently soliciting editors on non-English projects to test it out voluntarily on a sub-set of pages. Any projects that want to help shape the future of this software should pick a discussion space they want to use for testing and speak up. -- My team (Growth) has begun waiting for translations of experimental interfaces, so we can A/B test in many languages simultaneously. We're about to do this again in this month, by testing task recommendations in 12 languages right from the start.[4] We've done with other projects as well, like A/B testing changes aimed at anonymous editors in four languages. -- The Content Translation project is starting with Spanish and Catalan Wikipedias.[5]
After we get past the testing stage, none of this erases the fact that English Wikipedia is still the largest project by far, and is a major problem spot to be dealt with regarding issues related to new editor acquisition and retention. The data clearly suggests that it's a project we should be focusing on if we want to fix these problems, but we're certainly not ignoring others.
1). wikitech.wikimedia.org/view/Deployments 2). All technical staff and community contributors share English as their working language. Software gets built in English first obviously, so we don't have to wait on translations as a blocker for deployment. English Wikipedia is also our largest project, so we can get larger randomized samples during A/B tests. Making A/B tests shorter while also retaining accuracy is good. 3). https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan 4).
https://meta.wikimedia.org/wiki/Research:Task_recommendations/Experiment_one 5). https://www.mediawiki.org/wiki/Content_translation/Roadmap _______________________________________________ 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 Sat, Sep 6, 2014 at 9:07 AM, Steven Walling steven.walling@gmail.com wrote:
On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis.
This is rank hyperbole.
Oh, I love you too.
The MediaWiki deployment train delivers new software to all projects every week. One stage is to non-Wikipedia projects, which actually get new software *first.* Then in a second stage is for all Wikipedias simultaneously. So the default behavior for rollouts, if all you do is merge your code and wait, is that English Wikipedia gets basically no special treatment..[1]
That is unrelated; I am talking about 'features', which you address below...
Now, for larger feature rollouts like VisualEditor or MediaViewer, the testing stage and eventual launch set their own special schedule. We have used English Wikipedia as a testing ground a lot in the past, which is natural when you consider a variety of factors.[2] That doesn't mean we haven't worked hard to test things out with non-English projects.
I urge the WMF to rethink using English Wikipedia as their testing ground, as using it as the "natural" choice results in 'bad' designs and community engagement around deployment.
One of the more recent WMF products:
https://www.mediawiki.org/wiki/Extension:PageTriage
"An important note is that some of the configuration and code is specific to the English-language Wikipedia's workflows and as it's constructed now the extension is pretty much impossible to internationalize: developing a universal, stripped-down version is on our to-do list. (See bugzilla:48552.)"
[bugzilla 48552 was created May 2013, and prioritised as "Lowest" by James Forrester, and no change since.]
A lot of what I am suggesting is found in:
https://meta.wikimedia.org/wiki/User:Okeyes_(WMF)/Localising_page_curation
Flow is going to be a very major deploy. Do not make decisions about that deployment based on which language your engineers use at the water cooler or in commit messages. Employ the right people now to assist in a gradual deploy to communities that are ready for the pain involved.
My guess is the English Wikipedia community would prefer to know that Flow has been accepted on quite a few projects before it commences any migration. But maybe I am wrong; maybe that community will want to be a testing ground. Will you ask them?
-- John Vandenberg
On 5 September 2014 17:25, John Mark Vandenberg jayvdb@gmail.com wrote:
One of the more recent WMF products:
https://www.mediawiki.org/wiki/Extension:PageTriage
"An important note is that some of the configuration and code is specific to the English-language Wikipedia's workflows and as it's constructed now the extension is pretty much impossible to internationalize: developing a universal, stripped-down version is on our to-do list. (See bugzilla:48552.)"
[bugzilla 48552 was created May 2013, and prioritised as "Lowest" by James Forrester, and no change since.]
As a quick note, I prioritised it on behalf of the team who owned the product based on asking them; it's not my product, so it's not my call as to what the priority should be…
J.
2014-09-06 1:07 GMT+02:00 Steven Walling steven.walling@gmail.com:
On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis.
This is rank hyperbole.
The MediaWiki deployment train delivers new software to all projects every week. One stage is to non-Wikipedia projects, which actually get new software *first.* Then in a second stage is for all Wikipedias simultaneously. So the default behavior for rollouts, if all you do is merge your code and wait, is that English Wikipedia gets basically no special treatment..[1]
Now, for larger feature rollouts like VisualEditor or MediaViewer, the testing stage and eventual launch set their own special schedule. We have used English Wikipedia as a testing ground a lot in the past, which is natural when you consider a variety of factors.[2] That doesn't mean we haven't worked hard to test things out with non-English projects. Some examples:
I am sure you have tested things out on various wikis, but I can confirm that seeing things been rolled out from a non-English wiki, they multiple times look like if the English community has requested it or has been copied from. One (large) example is the TemplateData part of the VisualEditor which seems to us (nl-wiki) copied from the English Wikipedia, in multiple ways. This is not how we work with templates. And I can name many more examples.
Maybe it is not intended to adopt or specially fit with the English Wikipedia, if I compare software changes with the English Wikipedia and with the Dutch Wikipedia, most changes seem to fit exactly like the English Wikipedia and not with the Dutch Wikipedia. So many times it is locally thought and said that a change is likely "requested" by the English community.
Not that we make such big deal of it as we are already used to it, still this is how it is seen by at least some communities.
Romaine
On Sun, Sep 7, 2014 at 12:18 PM, Romaine Wiki romaine.wiki@gmail.com wrote:
2014-09-06 1:07 GMT+02:00 Steven Walling steven.walling@gmail.com:
On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis.
This is rank hyperbole.
The MediaWiki deployment train delivers new software to all projects every week. One stage is to non-Wikipedia projects, which actually get new software *first.* Then in a second stage is for all Wikipedias simultaneously. So the default behavior for rollouts, if all you do is merge your code and wait, is that English Wikipedia gets basically no special treatment..[1]
Now, for larger feature rollouts like VisualEditor or MediaViewer, the testing stage and eventual launch set their own special schedule. We have used English Wikipedia as a testing ground a lot in the past, which is natural when you consider a variety of factors.[2] That doesn't mean we haven't worked hard to test things out with non-English projects. Some examples:
I am sure you have tested things out on various wikis, but I can confirm that seeing things been rolled out from a non-English wiki, they multiple times look like if the English community has requested it or has been copied from. One (large) example is the TemplateData part of the VisualEditor which seems to us (nl-wiki) copied from the English Wikipedia, in multiple ways. This is not how we work with templates.
IIRC Visual Editor depends on writing TemplateData JSON for all your projects templates, using a mix of local language (parameter descriptions) and English (JSON keywords), which works real well for languages like Arabic and Hebrew.
-- John Vandenberg
On Mon, 25 Aug 2014, at 13:19, Pine W wrote:
I have heard very few people say "don't ever change the interface." I have heard people say "don't force an interface change on me that I don't think is an improvement."
VE was a good example. The sentiment of the community wasn't that VE''s concept is wrong, it's that the implementation and rollout had major deficiencies.
The MV issue is larger than than the usual editor-focused interface change because it impacts readers as well as editors, and there were issues with the display of licenses to readers. Personally I feel that the MV issues are fixable but the rollout should have been handled differently, and I am glad that the community and WMF both want to avoid repeating rollout problems again and again.
Pine
This instance is not new; https://meta.wikimedia.org/wiki/Limits_to_configuration_changes is a historical list of similar pattern in the relationship.
They already told you that they are doing this to not lose readers, so that fundraising keeps working. Tops you can do is, like the WMF folks remarked earlier, is have community work on what it needs "from the bottom up" "grassroots" etc.
A first step here, I believe, is have the Teams track bugs in the open; from my own experience, the Flow and Multimedia folks track bugs somewhere else where I can't even view or comment (and even if I could, it being different from Bugzilla would make things harder). I'm not sure what about migration to Phabricator, but I think it's an operations style of thing (I'm yet to figure out how to get involved, but it'd make it easier for anyone to work on the new features - they are really documented on-wiki (thankfully they only internalise only bug tracking atm), although so far only in English mostly).
svetlana
from my own experience, the Flow and Multimedia folks track bugs somewhere else where I can't even view or comment
Bugs and tasks are public for the Multimedia team. If you mean "bugs" in the bastardized sense of the term which is "things filed in bugzilla", then yes, the Multimedia team doesn't usually file building/refactoring tasks in bugzilla, we use mingle instead, which is public and can be commented on by everyone: http://ur1.ca/i1x3g We regularly link to our mingle cards on our mailing list updates, it's never been a secret area. I find that the mailing list is a better place for discussion, though, and we summarize in regular threads what tasks we're working on or planning to work on. In practice that's what's always happened anyway, people interested in what we're up to will reply to the detailed mailing list updates rather than comment on Mingle. Probably because Mingle's comment support is terrible.
As for actual bugs (defects) on products the Multimedia team is responsible for, they are currently tracked on bugzilla like everything else. It can happen ocassionally that we fix a bug and forget to file it in bugzilla, but generally speaking a bug/defect tracked in Mingle has a bugzilla counterpart. The existing disconnect and the fact that we sometimes forget to file a counterpart is one of the reasons we want to have a unified tool to do all the things people currently use bugzilla, mingle and trello for.
Our team will be one of the first to migrate to phabricator when the migration starts, because it will allow us to treat tasks, workload and defects in a single place. It will also give a much clearer view of what's going on to casual observers. The only reason why our team uses Mingle instead of Bugzilla for building tasks and triage is that Bugzilla offers no workload management and is often a poor fit for things that aren't defects. We're definitely not using Mingle to get things out of view (since it's public and regularly linked to), it's just that in the status quo Bugzilla alone didn't offer what we needed. I'm sure other teams use Trello and other tools for similar reasons. This is all coming from needs not covered by Bugzilla and we know very well how much that sucks in various ways, including the introduction of signup hurdles for people who want to interact with us, and the lack of discoverability, despite linking to Mingle every time we can. We certainly hope that the move to phabricator will make help people see and comment on what we're doing. Feeling like we're the only ones active on a particular tool is unhealthy for our projects, that's definitely not what we're looking for with phabricator, on the contrary.
On Mon, Aug 25, 2014 at 6:19 AM, svetlana svetlana@fastmail.com.au wrote:
On Mon, 25 Aug 2014, at 13:19, Pine W wrote:
I have heard very few people say "don't ever change the interface." I
have
heard people say "don't force an interface change on me that I don't
think
is an improvement."
VE was a good example. The sentiment of the community wasn't that VE''s concept is wrong, it's that the implementation and rollout had major deficiencies.
The MV issue is larger than than the usual editor-focused interface
change
because it impacts readers as well as editors, and there were issues with the display of licenses to readers. Personally I feel that the MV issues are fixable but the rollout should have been handled differently, and I
am
glad that the community and WMF both want to avoid repeating rollout problems again and again.
Pine
This instance is not new; https://meta.wikimedia.org/wiki/Limits_to_configuration_changes is a historical list of similar pattern in the relationship.
They already told you that they are doing this to not lose readers, so that fundraising keeps working. Tops you can do is, like the WMF folks remarked earlier, is have community work on what it needs "from the bottom up" "grassroots" etc.
A first step here, I believe, is have the Teams track bugs in the open; from my own experience, the Flow and Multimedia folks track bugs somewhere else where I can't even view or comment (and even if I could, it being different from Bugzilla would make things harder). I'm not sure what about migration to Phabricator, but I think it's an operations style of thing (I'm yet to figure out how to get involved, but it'd make it easier for anyone to work on the new features - they are really documented on-wiki (thankfully they only internalise only bug tracking atm), although so far only in English mostly).
svetlana
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, Given that it is pathetically easy to opt out of the MultimediaViewer, the amount of vitriol spouted by some is way out of proportion to the problem. If you do not want it, opt out. But thermonuclear was was threatened, people were to lose their job over this.
No the excuses are too little and too late. When people think that the change is not good for them opt out. What was said was a disgrace. It has never been in doubt that problems would be tackled.
Finally do not expect that much maintenance will be done on what is so lightly discarded. It is fine for you to stay with your "Internet 6". Improvements and subsequent development is just not for you. Thanks, GerardM
On 25 August 2014 05:19, Pine W wiki.pine@gmail.com wrote:
I have heard very few people say "don't ever change the interface." I have heard people say "don't force an interface change on me that I don't think is an improvement."
VE was a good example. The sentiment of the community wasn't that VE''s concept is wrong, it's that the implementation and rollout had major deficiencies.
The MV issue is larger than than the usual editor-focused interface change because it impacts readers as well as editors, and there were issues with the display of licenses to readers. Personally I feel that the MV issues are fixable but the rollout should have been handled differently, and I am glad that the community and WMF both want to avoid repeating rollout problems again and again.
Pine
On Sun, Aug 24, 2014 at 4:48 AM, Gerard Meijssen < gerard.meijssen@gmail.com> wrote:
Hoi, In the metrics meeting, a presentation was given that showed that mobile editing is really starting to happen. It is happening to the extend where new editors are predominantly mobile editors.
When I asked my question "do we need to keep you happy" I specifically targeted the vitriolic parts of our community. In my experience it it the part that is conservative, not willing to listen, not open to change and not willing to consider what is important to others.At Wikimania one of
the
presenters indicated that he was willing to contribute to Wikidata. This was not accepted because "someone in the community is really involved in this subject and he had to have a say". This was one major person
probably
walking away for ever who is hugely important in science and open data.
The
user interface for selecting fonts is abysmal because the "community" decided that what was implemented looked cluttered. Only seven percent of the world population is dyslexic and they do NOT find Wikipedia easier to read as a result.
Really, what is important to some people in the "community" is not necessarily beneficial at all. The lack of conversation the ease of
making
demands and not appreciating that our aim is to "share in the sum of all knowledge" means that many retarded points of view abound.
Erik indicated that he is willing to talk and come to a workable compromise. However, we do need change and we need it badly. When this is not understood, I am sorry to say, those who fail to understand this are
a
problem, a problem that is increasingly cancelling out their future
value.
Thanks, Gerard
On 24 August 2014 12:49, Dariusz Jemielniak darekj@alk.edu.pl wrote:
hi,
On Sun, Aug 24, 2014 at 11:07 AM, Gerard Meijssen < gerard.meijssen@gmail.com
wrote:
Now what do we aim to achieve? Keeping you happy or making sure we
have a
public ???
simply put: both. We need readers just as much as we need the free
labor
of
editors/volunteers.
I don't think it makes any sense to have a discussion about the "wasted millions". First, in software development there is always some
inevitable
waste, just because of the nature of this endeavor. Second, many
projects
which start with mixed reception are getting better (and I have high
hope
that the visual editor is one of them!). Third, for an IT organization
of
this caliber and traffic, as well as the budget, there are impressive results in many areas (including, but not limited to, mobile website -
at
least for viewers, as editing is a different story).
The real problem here, in my view, is creating an organizational
framework
that will allow to incorporate the community much more into planning,
early
development, alpha and beta testing, and finally implementation of all
new
features and tools (in a way which does not rely on IT schedules only,
but
also on feedback from the communities). It is up to WMF to create and provide such framework, as our community as a whole does not have any institutionalized representation or voice (which is part of the issue;
one
the one hand it is easy to discard whatever people from the community
say,
as they are random individuals, and on the other it must be deeply frustrating to never be sure what the community reaction will be). Some people are suggesting stewards as the good group to start with - I'm
afraid
stewards are not the best ones to go to. Stewards act mainly as highly trusted, experienced individuals. They do not represent their local communities in any way. Also, they do not necessarily have the best
skills
for the task, and they do not form a cooperating team, in general.
One of the unbearable signs of bureaucracy is setting up committees,
but
here a volunteer-driven, democratic task force could actually make some sense, perhaps. Look at it this way - we elect admins, crats,
checkusers,
oversighters, stewards. All these roles are only technical. Perhaps at
some
point we should think of community representation as well (and not in
the
sense of leadership, but in the sense of liaisons, testers, people responsible for smoother communication).
My experience within the FDC has shown that volunteer-driven bodies are quite effective at such tasks, when provided with necessary
organizational
support.
best,
dariusz "pundit"
--
prof. dr hab. Dariusz Jemielniak kierownik katedry Zarządzania Międzynarodowego i centrum badawczego CROW Akademia Leona Koźmińskiego http://www.crow.alk.edu.pl
członek Akademii Młodych Uczonych Polskiej Akademii Nauk _______________________________________________ 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
The issue is not just that individual users may want to opt out, it's whether it should be activated by default for readers. There is also the matter of licensing information.
I'm not aware of where "thermonuclear was was threatened". There were, and continues to be, discussion about forking. MV is merely the latest occurrence of products with major problems being pushed into production and made default. That needs to be addressed, and the fact that the problems with MV happened after AFT5 and VE *and* after the creation of the Engineering Community Liaisons suggests deep, long-term problems with product development. I believe that Lila said that the Board wants her to transform WMF and I am glad that there seems to be agreement that Product will be an early subject of transformation. I have reservations about forking for reasons that I can explain if necessary. It would be a lot easier if WMF would transform itself, starting with Product, and Lila appears to intend to make this happen. I hope that the processes for Product will be democratic and consensus-based. Grantmaking has already demonstrated the effectiveness of community-based decision making with FDC and IEGCom, and I hope to see a similar model emerge for Product. If it doesn't, there is enough anger in the community, especially on DEWP, that a fork is possible. The community is smart enough collectively to figure out a way to make a fork happen, and some of us have been discussing the mechanics of how this would work. We could do it, but reforming WMF is preferable. I hope that Lila can and will do this. Internal transofmration is preferable to replacing WMF.
Pine
Hoi, Actually the issue is no longer only that. It is also very much about how a subset of people high jack the conversation by their uncompromising stance. When they feel they might leave, I personally prefer it when they stop their posturing and decide either way.
When they want to stay, they do not need to be welcomed, they are part of us. When they go, they are welcome and they can take with them everything we have in the sense of data and software. It is then for them to show that their proof is in their pudding. In the mean time WMF will continue to engage in best practices both technically and socially and when they cook something nice, what is on offer is there for the eating as well.
As far as I am concerned, put up or shut up.
It has been advertised widely that bugs will be squashed. It is also advertised widely that changes will be considered as long as they are reasonable and do not interfere with our prime directive. Again, it is about the readers not super users. Thanks, GerardM
On 25 August 2014 11:16, Pine W wiki.pine@gmail.com wrote:
The issue is not just that individual users may want to opt out, it's whether it should be activated by default for readers. There is also the matter of licensing information.
I'm not aware of where "thermonuclear was was threatened". There were, and continues to be, discussion about forking. MV is merely the latest occurrence of products with major problems being pushed into production and made default. That needs to be addressed, and the fact that the problems with MV happened after AFT5 and VE *and* after the creation of the Engineering Community Liaisons suggests deep, long-term problems with product development. I believe that Lila said that the Board wants her to transform WMF and I am glad that there seems to be agreement that Product will be an early subject of transformation. I have reservations about forking for reasons that I can explain if necessary. It would be a lot easier if WMF would transform itself, starting with Product, and Lila appears to intend to make this happen. I hope that the processes for Product will be democratic and consensus-based. Grantmaking has already demonstrated the effectiveness of community-based decision making with FDC and IEGCom, and I hope to see a similar model emerge for Product. If it doesn't, there is enough anger in the community, especially on DEWP, that a fork is possible. The community is smart enough collectively to figure out a way to make a fork happen, and some of us have been discussing the mechanics of how this would work. We could do it, but reforming WMF is preferable. I hope that Lila can and will do this. Internal transofmration is preferable to replacing WMF.
Pine _______________________________________________ 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
WMF update: https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov_(WMF)&am...
Gerard, I agree that a forked wiki could have collaborations with WMF. But having separate hosting and legal ownership would create new headaches and risks. I hope WMF takes a cooperative and democratic approach so that we can work in harmony without forking.
There will almost always be people unhappy with major decisions. We should aim for consensus, not necessarily unanimous decisions. Recently it seemed to me that the consensus was leaning toward beginning a fork for at least DEWP. This is not a small subset of people who are upset with WMF.
Perhaps someone can explain what is so alarming about our readership stats and how MV is likely to improve our readership stats. To me the disappointing active editor stats are the biggest worry.
Thanks, Pine On Aug 26, 2014 3:14 AM, "Gerard Meijssen" gerard.meijssen@gmail.com wrote:
Hoi, Actually the issue is no longer only that. It is also very much about how a subset of people high jack the conversation by their uncompromising stance. When they feel they might leave, I personally prefer it when they stop their posturing and decide either way.
When they want to stay, they do not need to be welcomed, they are part of us. When they go, they are welcome and they can take with them everything we have in the sense of data and software. It is then for them to show that their proof is in their pudding. In the mean time WMF will continue to engage in best practices both technically and socially and when they cook something nice, what is on offer is there for the eating as well.
As far as I am concerned, put up or shut up.
It has been advertised widely that bugs will be squashed. It is also advertised widely that changes will be considered as long as they are reasonable and do not interfere with our prime directive. Again, it is about the readers not super users. Thanks, GerardM
On 25 August 2014 11:16, Pine W wiki.pine@gmail.com wrote:
The issue is not just that individual users may want to opt out, it's whether it should be activated by default for readers. There is also the matter of licensing information.
I'm not aware of where "thermonuclear was was threatened". There were,
and
continues to be, discussion about forking. MV is merely the latest occurrence of products with major problems being pushed into production
and
made default. That needs to be addressed, and the fact that the problems with MV happened after AFT5 and VE *and* after the creation of the Engineering Community Liaisons suggests deep, long-term problems with product development. I believe that Lila said that the Board wants her to transform WMF and I am glad that there seems to be agreement that Product will be an early subject of transformation. I have reservations about forking for reasons that I can explain if necessary. It would be a lot easier if WMF would transform itself, starting with Product, and Lila appears to intend to make this happen. I hope that the processes for Product will be democratic and consensus-based. Grantmaking has already demonstrated the effectiveness of community-based decision making with
FDC
and IEGCom, and I hope to see a similar model emerge for Product. If it doesn't, there is enough anger in the community, especially on DEWP,
that a
fork is possible. The community is smart enough collectively to figure
out
a way to make a fork happen, and some of us have been discussing the mechanics of how this would work. We could do it, but reforming WMF is preferable. I hope that Lila can and will do this. Internal
transofmration
is preferable to replacing WMF.
Pine _______________________________________________ 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 https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hoi, Such separate hostings and ownership would not be that much of a risk to the WMF. The challenges will be first and foremost with the separatists; then again it is firmly their choice. There will be benefits on both sides as well. The community that remains with the WMF will lose all of the separatists and they will sadly see some of them go. It will allow for the influx of new people and new ideas. The people that go will get a reality check; they will find out to what extend the things they fought battles over are actually worth it. I am sure that both communities will benefit.
When the people who talk about going their own way rethink their stance and start considering the other side of the coin it may lead to an equilibrium. However, the Visual Editor is not the only thing that will change the look and feel there is so much more happening and at that, a single community only considering its own is in effect a cul de sac.
When numbers of readers are to be our main worry, it should be obvious by now that both for editing and reading they are happening on the mobile, the tablet. This is were our new readers are happening. Maybe not necessarily in Europe but certainly in the global south. They have by definition a different mode of operandi and consequently much of our current bickering is only distracting from putting our efforts in welcoming our newbies and building a full fledged environment for them. Thanks, GerardM
On 28 August 2014 09:34, Pine W wiki.pine@gmail.com wrote:
WMF update:
https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov_(WMF)&am...
Gerard, I agree that a forked wiki could have collaborations with WMF. But having separate hosting and legal ownership would create new headaches and risks. I hope WMF takes a cooperative and democratic approach so that we can work in harmony without forking.
There will almost always be people unhappy with major decisions. We should aim for consensus, not necessarily unanimous decisions. Recently it seemed to me that the consensus was leaning toward beginning a fork for at least DEWP. This is not a small subset of people who are upset with WMF.
Perhaps someone can explain what is so alarming about our readership stats and how MV is likely to improve our readership stats. To me the disappointing active editor stats are the biggest worry.
Thanks, Pine On Aug 26, 2014 3:14 AM, "Gerard Meijssen" gerard.meijssen@gmail.com wrote:
Hoi, Actually the issue is no longer only that. It is also very much about
how a
subset of people high jack the conversation by their uncompromising
stance.
When they feel they might leave, I personally prefer it when they stop their posturing and decide either way.
When they want to stay, they do not need to be welcomed, they are part of us. When they go, they are welcome and they can take with them everything we have in the sense of data and software. It is then for them to show
that
their proof is in their pudding. In the mean time WMF will continue to engage in best practices both technically and socially and when they cook something nice, what is on offer is there for the eating as well.
As far as I am concerned, put up or shut up.
It has been advertised widely that bugs will be squashed. It is also advertised widely that changes will be considered as long as they are reasonable and do not interfere with our prime directive. Again, it is about the readers not super users. Thanks, GerardM
On 25 August 2014 11:16, Pine W wiki.pine@gmail.com wrote:
The issue is not just that individual users may want to opt out, it's whether it should be activated by default for readers. There is also
the
matter of licensing information.
I'm not aware of where "thermonuclear was was threatened". There were,
and
continues to be, discussion about forking. MV is merely the latest occurrence of products with major problems being pushed into production
and
made default. That needs to be addressed, and the fact that the
problems
with MV happened after AFT5 and VE *and* after the creation of the Engineering Community Liaisons suggests deep, long-term problems with product development. I believe that Lila said that the Board wants her
to
transform WMF and I am glad that there seems to be agreement that
Product
will be an early subject of transformation. I have reservations about forking for reasons that I can explain if necessary. It would be a lot easier if WMF would transform itself, starting with Product, and Lila appears to intend to make this happen. I hope that the processes for Product will be democratic and consensus-based. Grantmaking has already demonstrated the effectiveness of community-based decision making with
FDC
and IEGCom, and I hope to see a similar model emerge for Product. If it doesn't, there is enough anger in the community, especially on DEWP,
that a
fork is possible. The community is smart enough collectively to figure
out
a way to make a fork happen, and some of us have been discussing the mechanics of how this would work. We could do it, but reforming WMF is preferable. I hope that Lila can and will do this. Internal
transofmration
is preferable to replacing WMF.
Pine _______________________________________________ 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 <
https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wi...
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
I agree with Gerard, and would add that a good portion of the new readers and "missing female editors" do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the "first edit" experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure).
Sent from my iPad
On Aug 28, 2014, at 4:30 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Such separate hostings and ownership would not be that much of a risk to the WMF. The challenges will be first and foremost with the separatists; then again it is firmly their choice. There will be benefits on both sides as well. The community that remains with the WMF will lose all of the separatists and they will sadly see some of them go. It will allow for the influx of new people and new ideas. The people that go will get a reality check; they will find out to what extend the things they fought battles over are actually worth it. I am sure that both communities will benefit.
When the people who talk about going their own way rethink their stance and start considering the other side of the coin it may lead to an equilibrium. However, the Visual Editor is not the only thing that will change the look and feel there is so much more happening and at that, a single community only considering its own is in effect a cul de sac.
When numbers of readers are to be our main worry, it should be obvious by now that both for editing and reading they are happening on the mobile, the tablet. This is were our new readers are happening. Maybe not necessarily in Europe but certainly in the global south. They have by definition a different mode of operandi and consequently much of our current bickering is only distracting from putting our efforts in welcoming our newbies and building a full fledged environment for them. Thanks, GerardM
On 28 August 2014 09:34, Pine W wiki.pine@gmail.com wrote:
WMF update:
https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov_(WMF)&am...
Gerard, I agree that a forked wiki could have collaborations with WMF. But having separate hosting and legal ownership would create new headaches and risks. I hope WMF takes a cooperative and democratic approach so that we can work in harmony without forking.
There will almost always be people unhappy with major decisions. We should aim for consensus, not necessarily unanimous decisions. Recently it seemed to me that the consensus was leaning toward beginning a fork for at least DEWP. This is not a small subset of people who are upset with WMF.
Perhaps someone can explain what is so alarming about our readership stats and how MV is likely to improve our readership stats. To me the disappointing active editor stats are the biggest worry.
Thanks, Pine On Aug 26, 2014 3:14 AM, "Gerard Meijssen" gerard.meijssen@gmail.com wrote:
Hoi, Actually the issue is no longer only that. It is also very much about
how a
subset of people high jack the conversation by their uncompromising
stance.
When they feel they might leave, I personally prefer it when they stop their posturing and decide either way.
When they want to stay, they do not need to be welcomed, they are part of us. When they go, they are welcome and they can take with them everything we have in the sense of data and software. It is then for them to show
that
their proof is in their pudding. In the mean time WMF will continue to engage in best practices both technically and socially and when they cook something nice, what is on offer is there for the eating as well.
As far as I am concerned, put up or shut up.
It has been advertised widely that bugs will be squashed. It is also advertised widely that changes will be considered as long as they are reasonable and do not interfere with our prime directive. Again, it is about the readers not super users. Thanks, GerardM
On 25 August 2014 11:16, Pine W wiki.pine@gmail.com wrote:
The issue is not just that individual users may want to opt out, it's whether it should be activated by default for readers. There is also
the
matter of licensing information.
I'm not aware of where "thermonuclear was was threatened". There were,
and
continues to be, discussion about forking. MV is merely the latest occurrence of products with major problems being pushed into production
and
made default. That needs to be addressed, and the fact that the
problems
with MV happened after AFT5 and VE *and* after the creation of the Engineering Community Liaisons suggests deep, long-term problems with product development. I believe that Lila said that the Board wants her
to
transform WMF and I am glad that there seems to be agreement that
Product
will be an early subject of transformation. I have reservations about forking for reasons that I can explain if necessary. It would be a lot easier if WMF would transform itself, starting with Product, and Lila appears to intend to make this happen. I hope that the processes for Product will be democratic and consensus-based. Grantmaking has already demonstrated the effectiveness of community-based decision making with
FDC
and IEGCom, and I hope to see a similar model emerge for Product. If it doesn't, there is enough anger in the community, especially on DEWP,
that a
fork is possible. The community is smart enough collectively to figure
out
a way to make a fork happen, and some of us have been discussing the mechanics of how this would work. We could do it, but reforming WMF is preferable. I hope that Lila can and will do this. Internal
transofmration
is preferable to replacing WMF.
Pine _______________________________________________ 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 <
https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wi...
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 28 August 2014 12:56, Jane Darnell jane023@gmail.com wrote:
I agree with Gerard, and would add that a good portion of the new readers and "missing female editors" do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the "first edit" experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure).
mechanics of how this would work. We could do it, but reforming WMF is
Every year we see many expensive surveys and funded research on women and Wikipedia, so presumably there are some verifiable statistics to support Jane's assertion that a significant difference between readers of Wikipedia is that men are significantly more likely to own or have access to a desktop compared to women that they might edit from.
Can someone provide a link to the research that demonstrates this is more than apocryphal?
Thanks, Fae
You can start by asking around in your own circle of aquaintance, and I'll bet that such research will make you quickly realize that hard stats will be very hard to discover, since in my circle, most of the women I know are married and though their household contains a desktop, the desktop is owned and operated by their husband, not them. In any official questionaire served to them however, they are probably asked whether their household has one, not whether they themselves are the primary user of one.
On Thu, Aug 28, 2014 at 8:29 AM, Fæ faewik@gmail.com wrote:
On 28 August 2014 12:56, Jane Darnell jane023@gmail.com wrote:
I agree with Gerard, and would add that a good portion of the new
readers and "missing female editors" do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the "first edit" experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure). mechanics of how this would work. We could do it, but reforming WMF is
Every year we see many expensive surveys and funded research on women and Wikipedia, so presumably there are some verifiable statistics to support Jane's assertion that a significant difference between readers of Wikipedia is that men are significantly more likely to own or have access to a desktop compared to women that they might edit from.
Can someone provide a link to the research that demonstrates this is more than apocryphal?
Thanks, Fae -- faewik@gmail.com https://commons.wikimedia.org/wiki/User:Fae
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 Thu, Aug 28, 2014 at 6:55 AM, Jane Darnell jane023@gmail.com wrote:
You can start by asking around in your own circle of aquaintance, and I'll bet that such research will make you quickly realize that hard stats will be very hard to discover, since in my circle, most of the women I know are married and though their household contains a desktop, the desktop is owned and operated by their husband, not them.
I use (primarily) my carbon-fiber beast of a desktop, with my wife using primarily a laptop. The use of "desktop" to (presumably) refer to laptops is very confusing here, and would make accurate data gathering more difficult, not less.
We both use a tablet and/or phone, but only when away from the real machines or for very quick stuff. Doing real work on a tablet/phone is a pain in the ass, not just on Wikipedia but for anything. If I have a decent amount of text to type, I'll take a real keyboard and two monitors, not one "keyboard" taking up half of a 4" screen, thanks very much. I can't even imagine trying to make a significant edit to an article on a phone, no matter how good we make the interface. Even in a visual editor, articles require the entry of a lot of text, not the Facebook-style "I'm here, having a great time!"
That's a usage pattern that's very common with couples in my experience. It's apparently not in yours. That's why the plural of anecdote is not evidence.
In any official questionaire served to them however, they are probably asked whether their household has one, not whether they themselves are the primary user of one.
Why would they be? If we're trying to determine use patterns, it's silly to ask about the simple presence of something, but that's easy to fix.
"What device do you primarily use when accessing the Internet?" (Alternatively, or as a followup, "What type of device do you routinely use to access the Internet? Check all that apply.")
[ ] A desktop computer [ ] A laptop or notebook computer [ ] A tablet or smartphone
Not that hard to design a question that addresses the user directly, by not just access to a given device but actual use of it. If we need that data, we ought to actually gather it.
On Thu, Aug 28, 2014 at 8:29 AM, Fæ faewik@gmail.com wrote:
On 28 August 2014 12:56, Jane Darnell jane023@gmail.com wrote:
I agree with Gerard, and would add that a good portion of the new
readers and "missing female editors" do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the
new
readers are, but also where the "first edit" experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure). mechanics of how this would work. We could do it, but reforming WMF is
Every year we see many expensive surveys and funded research on women and Wikipedia, so presumably there are some verifiable statistics to support Jane's assertion that a significant difference between readers of Wikipedia is that men are significantly more likely to own or have access to a desktop compared to women that they might edit from.
Can someone provide a link to the research that demonstrates this is more than apocryphal?
Thanks, Fae -- faewik@gmail.com https://commons.wikimedia.org/wiki/User:Fae
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
I should explain that I am a resident of the Netherlands, where we have a central statistics bureau which includes census statistics that you can query for free and download your own datasets in xls format. As a data analyst I have spent lots of time gathering such data and reporting on it in Microsoft Excel, which is still my tool of choice. I frequently read news stories about published reports that misinterpret data and I sometimes will check the cited data against published open data sources. I base my conclusions on that experience as well as my personal experience. It may also be helpful to explain that many of my friends are or were stay-at-home moms. I agree that most of the questions served in public surveys do not seem to be formulated by data analysts.
I am proud to say that after a rocky start I can finally edit Wikipedia and Wikimedia Commons on my iPad, but I couldn't tell you what I did to set it up. I have successfully uploaded several photos with my android app to Wiki Loves Monuments. I do know that I tried to make an edit on someone else's iPhone this week and was stopped short by the mobile interface.
On Thu, Aug 28, 2014 at 9:35 AM, Todd Allen toddmallen@gmail.com wrote:
On Thu, Aug 28, 2014 at 6:55 AM, Jane Darnell jane023@gmail.com wrote:
You can start by asking around in your own circle of aquaintance, and
I'll
bet that such research will make you quickly realize that hard stats will be very hard to discover, since in my circle, most of the women I know
are
married and though their household contains a desktop, the desktop is
owned
and operated by their husband, not them.
I use (primarily) my carbon-fiber beast of a desktop, with my wife using primarily a laptop. The use of "desktop" to (presumably) refer to laptops is very confusing here, and would make accurate data gathering more difficult, not less.
We both use a tablet and/or phone, but only when away from the real machines or for very quick stuff. Doing real work on a tablet/phone is a pain in the ass, not just on Wikipedia but for anything. If I have a decent amount of text to type, I'll take a real keyboard and two monitors, not one "keyboard" taking up half of a 4" screen, thanks very much. I can't even imagine trying to make a significant edit to an article on a phone, no matter how good we make the interface. Even in a visual editor, articles require the entry of a lot of text, not the Facebook-style "I'm here, having a great time!"
That's a usage pattern that's very common with couples in my experience. It's apparently not in yours. That's why the plural of anecdote is not evidence.
In any official questionaire served to them however, they are probably asked whether their household
has
one, not whether they themselves are the primary user of one.
Why would they be? If we're trying to determine use patterns, it's silly to ask about the simple presence of something, but that's easy to fix.
"What device do you primarily use when accessing the Internet?" (Alternatively, or as a followup, "What type of device do you routinely use to access the Internet? Check all that apply.")
[ ] A desktop computer [ ] A laptop or notebook computer [ ] A tablet or smartphone
Not that hard to design a question that addresses the user directly, by not just access to a given device but actual use of it. If we need that data, we ought to actually gather it.
On Thu, Aug 28, 2014 at 8:29 AM, Fæ faewik@gmail.com wrote:
On 28 August 2014 12:56, Jane Darnell jane023@gmail.com wrote:
I agree with Gerard, and would add that a good portion of the new
readers and "missing female editors" do not own or operate a desktop
and
are only available on mobile and tablet, so this is not only where the
new
readers are, but also where the "first edit" experience is for most
women
(and sadly, a corollary to that is that they don't try again after
their
first edit failure). mechanics of how this would work. We could do it, but reforming WMF is
Every year we see many expensive surveys and funded research on women and Wikipedia, so presumably there are some verifiable statistics to support Jane's assertion that a significant difference between readers of Wikipedia is that men are significantly more likely to own or have access to a desktop compared to women that they might edit from.
Can someone provide a link to the research that demonstrates this is more than apocryphal?
Thanks, Fae -- faewik@gmail.com https://commons.wikimedia.org/wiki/User:Fae
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 8/28/14, 2:55 PM, Jane Darnell wrote:
You can start by asking around in your own circle of aquaintance, and I'll bet that such research will make you quickly realize that hard stats will be very hard to discover, since in my circle, most of the women I know are married and though their household contains a desktop, the desktop is owned and operated by their husband, not them.
This kind of analysis varies quite widely by country and community, so I would be wary of making wide generalizations. You say that "most of the women I know are married", but your experience would be unusual here (Denmark), because the hard statistics show that most adult women (and men) in the country are not married. Clearly other countries' statistics (and statistics for demographic subsets of the same) will show other numbers.
Best, Mark
On 30/08/2014, Mark delirium@hackish.org wrote:
On 8/28/14, 2:55 PM, Jane Darnell wrote:
You can start by asking around in your own circle of aquaintance, and I'll bet that such research will make you quickly realize that hard stats will be very hard to discover, since in my circle, most of the women I know are married and though their household contains a desktop, the desktop is owned and operated by their husband, not them.
This kind of analysis varies quite widely by country and community, so I would be wary of making wide generalizations. You say that "most of the women I know are married", but your experience would be unusual here (Denmark), because the hard statistics show that most adult women (and men) in the country are not married. Clearly other countries' statistics (and statistics for demographic subsets of the same) will show other numbers.
Best, Mark
I know widowers, unmarried people and same-sex married couples and almost no heterosexual married couples; hetero marriage seems a lot less popular these days. All the women I know either have their own machine or are uninterested in accessing the internet.
I honestly cannot think of any women in my circle of friends and acquaintances that rely on a husband or partner to access the internet, it is something I would find truly weird and would worry that the husband was being over-controlling. Though I have one friend that relies on free public internet for his access for cost reasons.
I have a relative stuck long term in a London hospital where they charge her 7 quid a day for internet access, which she cannot afford so she relies on visitors to do stuff on the internet and will spend her days reading books instead; I find that particularly shocking and I have never heard of Wikimedia being a champion for the right to free internet in hospitals - in the 1st world, that should be a lot easier to negotiate than the internet zero stuff in the developing world.
Fae
Hey Jane,
as the desktop is sometimes characterised only as a legacy input device for old power editors, while the reading is done from mobile devices, often in the form of mash-ups and geo-apps, why is a compromise so hard to achieve?
One solution that pops up would be to cache the content (as most useful wikipedia apps do anyway) in a light mobile version, while allowing an existing group of useful contributors their little island. This feeling of belonging makes those editors do all the dirty jobs noone wants to do on a regular basis - most of it fact and copyright checks that make the content so good it is useful to readers and keeps them coming back.
You could create a newbie-friendly version with rich text editing optimised for different devices, more customisation in an easy way... if we are realistic that would be the way to go anyway, as you can start out much easier and with less baggage - and would be able to target groups on an individual basis in the process, too. When they evolve in the ("bitter-vet") power users and editors, they can switch to the still more useful but less pretty interfaces for large data manipulation, that the desktop offers.
Shouldn't the focus be on the readers that read the content AND the editors that produce interesting content to make readers come back? Gerard in this regard seems to have a somehow bi-polar view of this process with his us - them characterisation ("the community that remains with the WMF will lose all of the separatists"). They will just no longer do the hard stuff, if they feel that they are not welcome - and finding such people is hard, really hard (speaking as a long-term gutenberg proof-reader).
cheers,
g
Thursday, August 28, 2014, 1:56:38 PM, you wrote:
I agree with Gerard, and would add that a good portion of the new readers and "missing female editors" do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the "first edit" experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure).
Sent from my iPad
On Aug 28, 2014, at 4:30 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Such separate hostings and ownership would not be that much of a risk to the WMF. The challenges will be first and foremost with the separatists; then again it is firmly their choice. There will be benefits on both sides as well. The community that remains with the WMF will lose all of the separatists and they will sadly see some of them go. It will allow for the influx of new people and new ideas. The people that go will get a reality check; they will find out to what extend the things they fought battles over are actually worth it. I am sure that both communities will benefit.
When the people who talk about going their own way rethink their stance and start considering the other side of the coin it may lead to an equilibrium. However, the Visual Editor is not the only thing that will change the look and feel there is so much more happening and at that, a single community only considering its own is in effect a cul de sac.
When numbers of readers are to be our main worry, it should be obvious by now that both for editing and reading they are happening on the mobile, the tablet. This is were our new readers are happening. Maybe not necessarily in Europe but certainly in the global south. They have by definition a different mode of operandi and consequently much of our current bickering is only distracting from putting our efforts in welcoming our newbies and building a full fledged environment for them. Thanks, GerardM
Hi g, Thanks for calling me an old power editor. I suggest you try to make an edit to a WIkimedia project of choice (e.g. add a photo to an existing article) on a desktop, then do the same on a mobile smartphone, and then report back here. Jane
On Thu, Aug 28, 2014 at 8:50 AM, ; ) box@gmx.at wrote:
Hey Jane,
as the desktop is sometimes characterised only as a legacy input device for old power editors, while the reading is done from mobile devices, often in the form of mash-ups and geo-apps, why is a compromise so hard to achieve?
One solution that pops up would be to cache the content (as most useful wikipedia apps do anyway) in a light mobile version, while allowing an existing group of useful contributors their little island. This feeling of belonging makes those editors do all the dirty jobs noone wants to do on a regular basis - most of it fact and copyright checks that make the content so good it is useful to readers and keeps them coming back.
You could create a newbie-friendly version with rich text editing optimised for different devices, more customisation in an easy way... if we are realistic that would be the way to go anyway, as you can start out much easier and with less baggage - and would be able to target groups on an individual basis in the process, too. When they evolve in the ("bitter-vet") power users and editors, they can switch to the still more useful but less pretty interfaces for large data manipulation, that the desktop offers.
Shouldn't the focus be on the readers that read the content AND the editors that produce interesting content to make readers come back? Gerard in this regard seems to have a somehow bi-polar view of this process with his us - them characterisation ("the community that remains with the WMF will lose all of the separatists"). They will just no longer do the hard stuff, if they feel that they are not welcome - and finding such people is hard, really hard (speaking as a long-term gutenberg proof-reader).
cheers,
g
Thursday, August 28, 2014, 1:56:38 PM, you wrote:
I agree with Gerard, and would add that a good portion of the new readers and "missing female editors" do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the "first edit" experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure).
Sent from my iPad
On Aug 28, 2014, at 4:30 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Such separate hostings and ownership would not be that much of a risk to the WMF. The challenges will be first and foremost with the separatists; then again it is firmly their choice. There will be benefits on both
sides
as well. The community that remains with the WMF will lose all of the separatists and they will sadly see some of them go. It will allow for
the
influx of new people and new ideas. The people that go will get a
reality
check; they will find out to what extend the things they fought battles over are actually worth it. I am sure that both communities will
benefit.
When the people who talk about going their own way rethink their stance
and
start considering the other side of the coin it may lead to an
equilibrium.
However, the Visual Editor is not the only thing that will change the
look
and feel there is so much more happening and at that, a single community only considering its own is in effect a cul de sac.
When numbers of readers are to be our main worry, it should be obvious
by
now that both for editing and reading they are happening on the mobile,
the
tablet. This is were our new readers are happening. Maybe not
necessarily
in Europe but certainly in the global south. They have by definition a different mode of operandi and consequently much of our current
bickering
is only distracting from putting our efforts in welcoming our newbies
and
building a full fledged environment for them. Thanks, GerardM
Hoi, Once people decide to leave, the situation is quite stark. There are those that do and there are those that do not. In my previous mail it should have been clear that I described the situation after the departure of many malcontents. That IS a bi-polar state obviously.
That is not to say that the desktop is not important. That is not to say that the tooling people use for advanced tasks is not important.
The point is very much that in a changing environment, tools that rely on a stable environment are not stable by definition.You cannot insist on such stability either. You cannot even insist that the tools that are usable are well designed and easily adaptable to change. Take for instance gadgets. A successful gadget it copied from Wiki to Wiki and in the process it needs to be localised and preferably it should take advantage of any future development. Work has been done to accomplish internationalisation and a more centralised development model. Once this is finished one gadget may exist on hundreds of wikis. That is a maintenance scenario.
Another disaster (IMHO) is that the wikidatafication of Commons is NOT the wikidatafication of multi-media files. The point is NOT that Commons needs to be done first, the point is that once Commons is "done", all other Wikis who have local uploads of multi-media files need to be wikidatified as well. There is NO reason why the result of the compromises reached in the Commons process will "obviously" fit elsewhere.When it is clear from the start that Commons is ONLY the first to be wikidatified, there is a better chance of getting involvement from people who feel strongly about the reasons why their Wiki does not upload to Commons. Their involvement will be a reality check to the Commoners that their POV is exactly that.
The Multimedia Viewer did a good job at showing the extend to which local edge cases like the German templates Fabrice mentioned in a recent list of accomplishments pose problems for central development. They exist, they need to be fixed and preferably only once. If not they will change in the future again.
Several volunteers like Roan became employees of the WMF exactly because they were pivotal in the dissemination of technology. When you look at the work they do, bringing thing back together IS one aspect of their accomplishments.
Things will break and when we do not want drama again and again, we need to embrace change and accept that particularly high end tools will break down regularly. My experience at Labs shows exactly that and it shows that as things get better organised downtime becomes less of an issue. It also shows that as our environment becomes more stable, the tools become more sophisticated and consequently more in need of a well architected environment.
What we have is the old problem of retro fitting architecture where chaos reigned supreme. We can do this and this "we" is most definitely an invitation to every Wikimedian. Thanks, GerardM
On 28 August 2014 14:50, ; ) box@gmx.at wrote:
Hey Jane,
as the desktop is sometimes characterised only as a legacy input device for old power editors, while the reading is done from mobile devices, often in the form of mash-ups and geo-apps, why is a compromise so hard to achieve?
One solution that pops up would be to cache the content (as most useful wikipedia apps do anyway) in a light mobile version, while allowing an existing group of useful contributors their little island. This feeling of belonging makes those editors do all the dirty jobs noone wants to do on a regular basis - most of it fact and copyright checks that make the content so good it is useful to readers and keeps them coming back.
You could create a newbie-friendly version with rich text editing optimised for different devices, more customisation in an easy way... if we are realistic that would be the way to go anyway, as you can start out much easier and with less baggage - and would be able to target groups on an individual basis in the process, too. When they evolve in the ("bitter-vet") power users and editors, they can switch to the still more useful but less pretty interfaces for large data manipulation, that the desktop offers.
Shouldn't the focus be on the readers that read the content AND the editors that produce interesting content to make readers come back? Gerard in this regard seems to have a somehow bi-polar view of this process with his us - them characterisation ("the community that remains with the WMF will lose all of the separatists"). They will just no longer do the hard stuff, if they feel that they are not welcome - and finding such people is hard, really hard (speaking as a long-term gutenberg proof-reader).
cheers,
g
Thursday, August 28, 2014, 1:56:38 PM, you wrote:
I agree with Gerard, and would add that a good portion of the new readers and "missing female editors" do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the "first edit" experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure).
Sent from my iPad
On Aug 28, 2014, at 4:30 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, Such separate hostings and ownership would not be that much of a risk to the WMF. The challenges will be first and foremost with the separatists; then again it is firmly their choice. There will be benefits on both
sides
as well. The community that remains with the WMF will lose all of the separatists and they will sadly see some of them go. It will allow for
the
influx of new people and new ideas. The people that go will get a
reality
check; they will find out to what extend the things they fought battles over are actually worth it. I am sure that both communities will
benefit.
When the people who talk about going their own way rethink their stance
and
start considering the other side of the coin it may lead to an
equilibrium.
However, the Visual Editor is not the only thing that will change the
look
and feel there is so much more happening and at that, a single community only considering its own is in effect a cul de sac.
When numbers of readers are to be our main worry, it should be obvious
by
now that both for editing and reading they are happening on the mobile,
the
tablet. This is were our new readers are happening. Maybe not
necessarily
in Europe but certainly in the global south. They have by definition a different mode of operandi and consequently much of our current
bickering
is only distracting from putting our efforts in welcoming our newbies
and
building a full fledged environment for them. Thanks, GerardM
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 Fri, Aug 22, 2014 at 4:05 AM, Henning Schlottmann h.schlottmann@gmx.net wrote:
- The criticism isn't just about that -- it's about a large number of
mostly individually small issues. Generally, the idea that we effectively "munge" some of the metadata by displaying a machine-readable subset below the fold is viewed very negatively, because 1) it doesn't reflect all the available information, 2) it makes it harder for users to discover the File: page, and potentially edit it.
If it does not reflect the license information it is broken. We do not want
First, I think it's worthwhile in these discussions - in a context of a project where consensus is important - to remember that there are actually many different perspectives on Media Viewer in the community. Even in German Wikipedia, 72 community members voted _against_ disabling Media Viewer (more in absolute terms, incidentally, than voted for disabling it on English Wikipedia's RFC).
German Wikipedians have blogged about the fair amount of FUD that specifically surrounds licensing and attribution issues, pointing out that already, Media Viewer makes it far easier for re-users to consistently attribute authorship and license information, and provides more prominent copyright notices right below the image.
http://lieselsartikel.wordpress.com/2014/08/25/die-unwahrheiten-der-wmf-medi... http://erinnerungshort.de/blog/eine-lanze-fuer-den-medienbetrachter/
So if we care about consensus, why pretend these voices _in the community_ are irrelevant and wrong, rather than listening to their reasoned arguments?
And that's the current state. I think with a little bit of effort, we can deliver improvements that will give re-users concise hints that are far more effective at conveying the information hidden in walls of text today.
To be clear: The CC license text makes allowances for "reasonableness" - and in automated re-use, whether it's in Media Viewer or elsewhere, referring to the File: page in the absence of machine-readable data is an absolutely defensible, reasonable decision (and one which was vetted by WMF's legal team).
We certainly must work together to clean up the mess that is metadata on Commons, but to block all re-use that does not include an exact replica of the beautiful insanity of File: page templates until such a time that every piece of information contained therein is exactly represented in well-structured property/value pairs that can be predictably extracted is .. unreasonable.
In any case, many of your favorite examples of de.wp local uploads correctly display the author name and license now, e.g.: https://de.wikipedia.org/wiki/Olympiastadion_Athen#mediaviewer/Datei:2014_-_...
This is thanks to community members who worked with us to update the respective templates to add machine-readable data :). As I mentioned earlier, it's a totally fair criticism that our outreach efforts on this front were insufficient. There are still some templates left to be updated, and Gergo is preparing a more comprehensive cross-wiki assessment of templates in other languages/projects.
We do not want a default setting, that does not show extensive descriptions, map legends, image annotations and the like. All that is content we created for the readers. You must not block our readers from this content.
Again, the idea that software is not complete until it parses this:
[[:en:William Thomas Green Morton|William Thomas Green Morton]] {{ImageNoteEnd|id=1}} {{ImageNote|id=2|x=173|y=363|w=65|h=110|dimx=1600|dimy=1153|style=2}} [[:en:James Bogardus|James Bogardus]] {{ImageNoteEnd|id=2}} {{ImageNote|id=3|x=235|y=365|w=78|h=108|dimx=1600|dimy=1153|style=2}} [[:en:Samuel Colt|Samuel Colt]] {{ImageNoteEnd|id=3}} {{ImageNote|id=4|x=310|y=360|w=90|h=110|dimx=1600|dimy=1153|style=2}} [[:en:Cyrus Hall McCormick|Cyrus Hall McCormick]] {{ImageNoteEnd|id=4}} {{ImageNote|id=5|x=370|y=365|w=68|h=95|dimx=1600|dimy=1153|style=2}} [[:en:Joseph Saxton|Joseph Saxton]] {{ImageNoteEnd|id=5}} {{ImageNote|id=6|x=573|y=510|w=90|h=98|dimx=1600|dimy=1153|style=2}} [[:en:Charles Goodyear|Charles Goodyear]] {{ImageNoteEnd|id=6}} {{ImageNote|id=7|x=588|y=430|w=85|h=93|dimx=1600|dimy=1153|style=2}} [[:en:Peter Cooper|Peter Cooper]] {{ImageNoteEnd|id=7}} {{ImageNote|id=8|x=650|y=510|w=80|h=80|dimx=1600|dimy=1153|style=2}} [[:en:Jordan Lawrence Mott|Jordan Lawrence Mott]]
is unreasonable. If that's your standard of "broken" and "abysmal track record", your rhetoric is a bit exaggerated, but perhaps the reference to "black uniforms and heavy boots" in an earlier message was a dead giveaway.
Image annotations loaded via the community-created gadget are a beautiful hack (indeed one of my favorite gadgets of all time), and if the current implementation can be rendered in MediaViewer without negative performance impact and at reasonable cost, we'll get there. If not, let's migrate these annotations to a more supportable system in the long run and treat it as a File: page feature for now.
The more reasonable thing to ask for (which we've already implemented in the prototype) is a more prominent link to the File: page which encourages people to go down the rabbit hole if they want to, while giving them a quick image preview to begin with.
Erik
On 26 August 2014 09:39, Erik Moeller erik@wikimedia.org wrote:
First, I think it's worthwhile in these discussions - in a context of a project where consensus is important - to remember that there are actually many different perspectives on Media Viewer in the community. Even in German Wikipedia, 72 community members voted _against_ disabling Media Viewer
Hey you are the one currently ignoring 664 German wikipedians. Thats not logically consistent with objecting to people ignoring smaller numbers.
(more in absolute terms, incidentally, than voted for disabling it on English Wikipedia's RFC).
You want en to stick a link in sitenotice and up the numbers?
On 08/22/2014 01:54 AM, rupert THURNER wrote:
is the conflict not only triggered by a deliverable which was not good enough?
Part of the difficulty of that statement is that the very /definition/ of "good enough" will necessarily vary from individual to individual, with a non-zero segment of editors defining it as "absolutely perfect and matching /my/ requirements exactly" (and another, just as large segment, calling for "any improvement to X is a gain").
Regardless of one's opinions on the "power dynamics" of the situation, or on how to best serve the short- and long-term needs of the community, it seems to me evident that you cannot allow any one segment of the community what amounts to veto power to any attempts at improvement.
So the difficulty becomes simply one of finding a way to adjucate. It seems to me that *any* movement in that direction is an improvement, so long as it does not devolve in a simple game of numbers. It needs informed opinion, not popularity polls.
-- Marc
On 22 August 2014 14:42, Marc A. Pelletier marc@uberbox.org wrote:
Part of the difficulty of that statement is that the very /definition/ of "good enough" will necessarily vary from individual to individual, with a non-zero segment of editors defining it as "absolutely perfect and matching /my/ requirements exactly" (and another, just as large segment, calling for "any improvement to X is a gain").
Just recently I had someone seriously claim "bah, if Flow doesn't include [obscure feature I like] it won't be fit for purpose" in all seriousness.
Regardless of one's opinions on the "power dynamics" of the situation, or on how to best serve the short- and long-term needs of the community, it seems to me evident that you cannot allow any one segment of the community what amounts to veto power to any attempts at improvement.
I think it's indisputably clear that, no matter the level of and efforts toward consultation, people will loudly claim it wasn't enough.
- d.
On 08/21/2014 07:17 PM, Erik Moeller wrote:
It's very different futures -- a WMF that exists purely to do what communities ask it to, or a WMF that exists - in part - to look forward, close gaps, and help anticipate where we want to be 3, 5, 10 years from now. Irrespective of what my own take might be, both approaches do truly have their merits.
Along the same lines (by my reading) a week ago...
On 08/14/2014 02:57 AM, Erik Moeller wrote:
If you want a WMF that slavishly implements RFCs or votes to disable features upon request, you'll need to petition to replace more than just one person. In fact, you should petition to reduce the staff dramatically, find an administrative ED who has no opinion on what to do, and exclusively focus on platform-level improvements and requests that clearly have community backing.
I'd enjoy reading about these very different futures. As a mostly casual observer/fan of the various organizations and individuals of Wikimedia, the futures don't seem necessarily different.
On looking forward -- big developments such as Wikidata (some kind of semantic wiki database; yay!), Visual Editor (WYSIWYG editing), Multimedia Viewer (more usable Commons; of these MV addresses the smallest slice of the corresponding ur-wish), and Flow (more usable talk pages) each reflect wishes expressed by many Wikip/medians for almost as long as Wikipedia and Commons have existed, probably your expressions and experiments being among the very earliest.
On resources, making reasonably fast progress only on features with strong community backing would require a large paid staff, preferably larger than what exists now.
In my limited view, WMF isn't especially visionary nor is it especially authoritarian. What it has uniquely is the ability to do relatively massive fundraising, and thus bring concentrated resources to bear.
I don't care about deployment disputes, and probably would never be aware of them if I didn't follow this list and know some more active Wikimedians socially. Hopefully some process is worked out that all in some years see as a great innovation, or minimally, that all can forget there was any dispute about.
But I am kind of concerned about what I perceive as an underlying theme, with deployment disputes as a side effect: WMF as a product development organization, some of the most passionate users of its products as obstacles to innovation and optimization. That may be how other top n websites are operated, but that's also how more numerous former top n websites operated (of course I have no data). In the case of commons-based peer production sites like Wikimedia ones, that dynamic seems especially risky on one hand, and on the other, not leveraging the their strengths. If communities aren't looking forward and anticipating where we want to be 3, 5, 10 years from now (presumably facilitated by WMF; I admired the strategy process some years ago but admittedly didn't follow it closely enough to have an informed opinion) that's a serious gap to close.
I expect all to muddle through, but seriously I would love to read about (and see fully realized perhaps in new commons-based peer production projects without organizational history) what exciting things WMF would do if users weren't of concern (except as revealed by aggregate data and experiments), and what a somehow user-direct-democracy version would do. For my reading/observing satisfaction, I'd like them to have very different results. Maybe former would quickly implement lessons from gaming, some described by http://www.raphkoster.com/2014/08/12/wikipedia-is-a-game/ (I'd enjoy seeing them all tried in some commons-based peer production system)? Maybe latter would use all that power to reform itself into being predominantly friendly and welcoming (harder to imagine, but I'd love to be surprised)? Or maybe the reverse!?
Mike
Erik Moeller wrote:
I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it.
I think making amends requires cleaning up the mess you've made on the German Wikipedia and throughout the Wikimedia ecosystem. I don't think many German Wikipedians or other Wikimedians will be willing to accept your apology until super-protection is disabled. I hope you've been following https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Superschutz.
Our processes clearly need to be improved to avoid these situations in the future. We recognize that simply rejecting a community request rather than resolving a conflict together is not the right answer.
For sure. Thank you for this write-up.
But I continue to get the sense that the Wikimedia Foundation is looking for ways to ask (and re-ask) "how much would you like to pay for this horse?" and the editing community is responding with "no thank you, but we would perhaps consider a car."
In the specific case, I think there's a common interest in improving file description pages. Wikimedia readers and editors would certainly benefit, as would MediaWiki users. File description pages could certainly use design love, but rather than properly integrating with and improving MediaWiki, we ended up with some JavaScript slapped on top via an extension. There's a fundamental design flaw here, isn't there?
* The situation without MediaViewer: user clicks on an image, all the other content goes away, user is presented with a larger version of the image, its history, editing capability, and user can click the browser back button to return to the other content.
* The situation with MediaViewer: user clicks on an image, all the other content goes away, user is presented with a larger version of the image, no history or editing capability, and user can click the browser back button to return to the other content.
This is not really an improvement. Finite design and development resources are being invested in new tools and what's the end result? And of course MediaViewer came with an even higher cost given subsequent events.
In the general case, I think there are plenty of multimedia-related areas in which Commoners and others would love design and development resources: improved search (by file type, file size, color, content, etc.), an in-browser SVG editor, an in-browser rasterized photo editor (even basic support for cropping or rotating an image), the ability to easily rename a category, and so on. I'm not sure why MediaViewer was worth the steep cost.
But more to the point, I think it would be helpful if the Wikimedia Foundation could articulate a clear message about why these types of "reader-focused" features are a worthwhile investment. I talk to a lot of people about Wikipedia and the one complaint I _never_ hear is that Wikipedia has a readership problem. It's a fact that the Wikimedia Foundation typically embraces at every opportunity ("top-five Web site"). When I see reader-focused features such as ArticleFeedback and MoodBar and MediaViewer being given substantial priority, urgency, and visibility, I wonder what the rationale is. These types of features almost certainly aren't attracting more readers and anecdotally they seem to be damaging editors' relationships with the projects. Not exactly a great investment.
Despite the events of the past few weeks, I continue to trust you and I'm hopeful about the path forward you and Lila have laid out regarding community involvement in product development. Though it leads me to wonder what the status is for hiring a VP of Engineering so that you can focus exclusively on being the VP of Product Development.
MZMcBride
On Tue, Aug 19, 2014 at 6:09 PM, MZMcBride z@mzmcbride.com wrote:
I don't think many German Wikipedians or other Wikimedians will be willing to accept your apology until super-protection is disabled.
Our suggestion, which we posted on German Wikipedia, is that we spend some time talking to each other (up to 30 days, so not some indefinite procrastination) without efforts to disable features via JavaScript hacks, and without the page lock, to see if we can come to an agreement on how to resolve the conflict. This is currently under discussion there.
It would be disingenuous for WMF to declare "We will absolutely refrain from using such a restriction ever again". In a conflict, my recommendation is not to ask for a concession that would be only made disingenuously, because it will not last. WMF, organizationally (as has been made abundantly clear by Lila and the Board), is not committed to the idea that some community members want us to be - that we must always follow the outcome of a local vote or poll asking us to do something, to its letter, without any room for discussion.
The underlying reasoning is simple - WMF wants to help ensure that decisions are rational and well-informed consistent with its understanding of a given situation, that we have a level of baseline consistency of user experience, and that we challenge ourselves to think through changes that may take some getting used to, but may represent a long term improvement (with some allowance for iteration).
I know there are some who want to use this opportunity to cement a different relationship - "WMF as servant", without a say. ("You are the servant, not the master, and your opinion doesn't matter very much." [1]) I understand that - I think it's rational, and justifiable, and may even be the better direction in the long run. I personally happen to disagree strongly with that belief, and the organization's leadership certainly does, as well. I hope we can find a middle ground, and I know that some of this is also just a reaction.
We understand that the only path forward that may be acceptable to both parties is to act in a manner consistent with the principle of "shared power", which is why we suggest that we take some time to talk things through with both parties refraining from using technical or other means to force an outcome, and ideally aiming to completely obviate any kind of escalation like this in future.
What's happening here is painful and difficult, and I'm sorry for our role in that. I do believe it's necessary that we work through this, and on a personal level, I honestly care more about doing that and achieving some clarity on our working relationship with each other, than about any specific outcome.
But more to the point, I think it would be helpful if the Wikimedia Foundation could articulate a clear message about why these types of "reader-focused" features are a worthwhile investment. I talk to a lot of people about Wikipedia and the one complaint I _never_ hear is that Wikipedia has a readership problem. It's a fact that the Wikimedia Foundation typically embraces at every opportunity ("top-five Web site").
We are seeing pageviews flatten out, with most readership growth coming from mobile at this point. It's not alarming yet - it's consistent with the overall changes in user behavior - but of course it does mean that especially the experience across devices is becoming increasingly important.
The bulk of WMF's product development effort currently goes towards contribution, not presentation, but we try to ensure that we have an appropriate share of effort to modernize and improve the presentation of information as a whole, to make it easier for people to navigate, discover, re-use, etc. If you take a look at the mobile experience in a desktop browser, you'll find it not so different from many redesigns - large, readable text, narrower measure, deliberately chosen typography, minimal clutter, easier access to footnotes, etc.
http://en.m.wikipedia.org/wiki/Liber_Eliensis
Needless to say, it's a lot easier to try new design ideas here, since the level of investment of the community in the mobile experience is not as great yet (it is growing, which will again increase the need for us to have clear rules of engagement) and therefore the tolerance for smaller imperfections is higher. This has enabled a healthy pipeline of moving design changes from mobile to desktop - e.g. the typography changes, and the soon to come frameless thumbs.
What does "modernize" really mean? Well, it means adapting to a changing environment. Connections get faster, browsers become more powerful, screen resolutions increase, web typography improves, new interaction patterns become established in people's brains. In design practice, this has had a number of effects for modern sites, including larger images, greater focus on readable text, less clutter, etc.
It's appropriate for WMF to take into account the full breadth and depth of devices that do exist and are in wide usage, more so than sites developed for users in rich countries. Hence a greater focus on things like image compression, overall page footprint, the no-JavaScript experience, etc. But that's still consistent with carefully updating the presentation. (Introducing a lightbox viewer in 2014 is not exactly a radically new vision for user experience.)
People have cited WikiWand as an example of a third party improved reader experience. It's quite nicely done; I like a lot of the design choices they've made. It's far from a threat (though a more prominent "Edit" link would be nice, especially since the browser extension hijacks wikipedia.org views), but it's the kind of cool third party effort that keeps us honest. They recently raised about $600K in funding, which means that at least some people believe there's a real demand for a nicer, more modern default reader experience.
As a footnote, it shouldn't come as much of a surprise that WikiWand includes a lightbox image viewer. I think it's better in some ways than ours (e.g. I like the intelligent resizing of the image as you expand the info panel, allowing you to browse at different sizes with or without the full panel visible; also some nice subtle touches with the animations). It gives less prominent attribution than MV does (you have to expand it first), struggles with the same files that have insanely complex descriptions, and fails on the same files with a simple "License: Unkown" when no machine-readable data is available. No full-size zoom or re-use features, as far as I can tell, but a nice carousel navigation. (Just the kinds of things some people name as reasons MV should never have seen the light of day, incidentally.)
Why is that interaction pattern so commonly used? Because it's a smaller initial mental break when you read a text and want to simply examine something like a photo, a map, or an illustration. Progressive disclosure patterns are used to show additional information as appropriate, with the initial focus being on the image and its caption (using the same text that's used in the article, again both because that text is likely the most immediately relevant, and it reduces the cognitive break). Fast access to other media in the same article can be a nice bonus for articles that are visually rich and readers who are oriented to learning or discovering information in this manner.
Erik
[1] https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov&diff...
Thank you for a really good post.
Erik Moeller wrote:
I know there are some who want to use this opportunity to cement a different relationship - "WMF as servant", without a say. ("You are the servant, not the master, and your opinion doesn't matter very much." [1]) I understand that - I think it's rational, and justifiable, and may even be the better direction in the long run. I personally happen to disagree strongly with that belief, and the organization's leadership certainly does, as well. I hope we can find a middle ground, and I know that some of this is also just a reaction.
I appreciate the candor here and the recognition that there are acceptable yet radically different views of how the Wikimedia Foundation should fit within the Wikimedia world.
What's happening here is painful and difficult, and I'm sorry for our role in that. I do believe it's necessary that we work through this, and on a personal level, I honestly care more about doing that and achieving some clarity on our working relationship with each other, than about any specific outcome.
Re: https://meta.wikimedia.org/wiki/Limits_to_configuration_changes
The reality is that sometimes the wiki communities can make poor decisions. But Sj and Brion and others have, in my opinion, tried to stress that it's okay for people to be wrong and it's okay to try things out. But it's always been a balancing act.
If there aren't technical, legal, or fundamental philosophical issues with a wiki configuration change, when should and shouldn't it be allowed? And who ultimately decides (e.g., stewards)? I think that's roughly what we're looking at right now. The past process has sometimes relied on collective and intentional deafness (via Bugzilla or mailing lists or whatever) and that isn't really still suitable these days, I don't think.
Defining the third category (fundamental philosophical issues) is tricky, but retaining open content licenses, the ability of people to easily contribute, etc. are the types of things I'm talking about. Deeply held shared values, not "I think Web users should always have a lightbox when they click an image." That's an aesthetic choice that should probably be left up to individual communities unless we can find a compelling reason not to (e.g., having an identical user experience across Wikimedia wikis by globally enabling MediaViewer is not a fundamental philosophical issue and these types of aesthetic choices have never been considered as such).
It's appropriate for WMF to take into account the full breadth and depth of devices that do exist and are in wide usage, more so than sites developed for users in rich countries. Hence a greater focus on things like image compression, overall page footprint, the no-JavaScript experience, etc. But that's still consistent with carefully updating the presentation. (Introducing a lightbox viewer in 2014 is not exactly a radically new vision for user experience.)
Yes. Performance is important. Graceful degradation is important.
People have cited WikiWand as an example of a third party improved reader experience. It's quite nicely done; I like a lot of the design choices they've made. It's far from a threat (though a more prominent "Edit" link would be nice, especially since the browser extension hijacks wikipedia.org views), but it's the kind of cool third party effort that keeps us honest. They recently raised about $600K in funding, which means that at least some people believe there's a real demand for a nicer, more modern default reader experience.
At http://news.slashdot.org/story/14/08/21/216217/ Andreas Kolbe discusses WikiWand. In Andreas' view, "the Wikimedia Foundation is afraid it will lose readers to sites like WikiWand that offer Wikipedia content as a pure consumable with a much more aesthetically pleasing interface. The moment Wikipedia page views go down, the Alexa rank will go down and donations will go down, as fewer people will see the fundraising banners."
Pi zero at https://meta.wikimedia.org/wiki/Special:Permalink/9622503 writes, "The non-Wikipedian sisters are the growth sector of the wikimedian movement, and the WMF by dissing them is strangling the wikimedian movement's best chance of having a vigorous future, with Wikipedia embedded in a thriving ecosystem of wikimedian sisters augmenting each other's strengths."
Meanwhile Lila has been repeatedly emphasizing priorities and prioritization on Meta-Wiki (in seven distinct posts, by my count). There are vague references to the "prioritization pipeline," but in addition to the issue of deciding wiki configuration changes, discussed above, we also need to clearly define what that pipeline looks like and how it behaves. Pine and others have been discussing a Technology Committee that could possibly bridge the Board, Wikimedia Foundation staff, and the editing communities. But who knows if such an idea is viable or desirable.
There is lots and lots to think about right now.
MZMcBride
On Sun, Aug 24, 2014 at 4:38 AM, MZMcBride z@mzmcbride.com wrote:
Pi zero at https://meta.wikimedia.org/wiki/Special:Permalink/9622503 writes, "The non-Wikipedian sisters are the growth sector of the wikimedian movement, and the WMF by dissing them is strangling the wikimedian movement's best chance of having a vigorous future, with Wikipedia embedded in a thriving ecosystem of wikimedian sisters augmenting each other's strengths."
Thanks MZMcBride for bringing attention to Pi Zero's insightful comment, which actually correspond with how big companies devise strategies to be successful. They do not promote only one brand, they promote several with the hopes that, if one dies, they will have another one (or several) to take up its place. If you look at companies that failed in the past, most of the ones that could have avoided their fate didn't or couldn't, because they had over-commited to a single product, and when that failed they had no back-up plan with products better adapted to the new conditions, and someone else had occupied that market slot. It is always wise to have several baskets where to put eggs.
The biggest asset of the Wikimedia stream is not that its community can materialize around a digital encyclopedia, but that it can do so around many other projects that are also aligned with the mission of sharing and opening knowledge. And those opportunities have *increased* over time.
There are people who are concerned about public spending, others that are concerned about creating reliable medical information, others about adapting information for schoolchildren, others about collaborative and open science, etc. if you look at the past proposed projects or adoption requests the list goes on and on, and of those many only one was adopted. It is never sure which one is going to be succesful, but if several are not tried, then for sure they will fail because they lack leverage.
I think the biggest fear in the past was to stretch too much, or to not be able to re-integrate the generated information into a central space (like Wikipedia), but that is now less so. Wikidata is starting to become the central information backbone, and what in the past looked disperse, now can be put back together with little effort, no matter where one contributed.
One of the ideas I liked the most in Wikimania is that we could have several projects adapted to the interest of each person or community, with a fresh start, without so many rules, with new tools deployed there, and generating information that can be merged back into a central space if wished so. What is stopping us of having medical.wikipedia.org? Or education.wikipedia.org?
I think the recent drama around MV shows that you can't teach an old dog new tricks, or at least not as fast as the changing situation requires. If the existing strategy is not working, and if after these years the editor decline couldn't be stopped. Why not to try something different?
Thanks Micru
On Thu, Aug 21, 2014 at 10:35 PM, Erik Moeller erik@wikimedia.org wrote:
If you take a look at the mobile experience in a desktop browser, you'll find it not so different from many redesigns
- large, readable text, narrower measure, deliberately chosen
typography, minimal clutter, easier access to footnotes, etc.
And the design community is taking notice: https://news.layervault.com/stories/31897-wikipedia-already-looks-great--jus...
On 27 August 2014 05:16, Erik Moeller erik@wikimedia.org wrote:
And the design community is taking notice:
https://news.layervault.com/stories/31897-wikipedia-already-looks-great--jus...
We already know the design community doesn't like the edit button. Was there any reason you thought we should pay attention to their opinion?
What the heck is a "design community" at all, and why does their opinion count, when WMF uses every opportunity to claim it is super-unfair to claim that "the community" wants anything?
2014-08-27 6:49 GMT+02:00 geni geniice@gmail.com:
On 27 August 2014 05:16, Erik Moeller erik@wikimedia.org wrote:
And the design community is taking notice:
https://news.layervault.com/stories/31897-wikipedia-already-looks-great--jus...
We already know the design community doesn't like the edit button. Was there any reason you thought we should pay attention to their opinion? -- geni _______________________________________________ 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 all,
Thank you Erik for your mail. It shows that the WMF is willing to discuss rather than to impose its solution.
I am really shocked that the dispute reaches that level of confrontation, and although some community members have a hard stance, this is largely due to WMF actions, specially the creation of the "superprotect" right. This is the worst possible step the WMF could make to find a solution for this issue.
Initially I was quite neutral about the MediaWiever, but I became increasingly skeptical. IMO it is hardly a priority, even for readers. Even if I am a long term contributor of Wikimedia projects, I am also a heavy reader of Wikipedia. I think that if a feature is refused in masse for the most active contributors, there is something wrong either in the feature itself, or in the way it is proposed to the projects. The WMF can certainly bring useful new additions in term of software development, but the implementation has to be done in a partnership with volunteer contributors. I cannot understand that the WMF in spite of its multi-million dollars budget is not able to convince volunteer contributors that the new feature is beneficial to the projects, either because it is technically very good, or that even with some shortcomings, it would improve the reading experience.
I am quite willing to test beta software, and I think there is no urgency to impose the MediaWiever now to everybody. I could be done after some time, when all issues have been sorted out. In term of media management, the most urgent and important thing is to fix the UploadWizard. Viewing images with Mediawiki may not be optimal, but it is not broken. The UploadWizard is broken.
Regards,
Yann
2014-08-20 0:42 GMT+05:30 Erik Moeller erik@wikimedia.org:
Hi folks,
This is a response to Martin's note here: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
.. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward.
I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it.
I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page.
Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a "better hack" to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint.
Our processes clearly need to be improved to avoid these situations in the future. We recognize that simply rejecting a community request rather than resolving a conflict together is not the right answer. We’ve been listening to feedback, and we’ve come to the following conclusions:
- We intend to undertake a review of our present processes immediately
and propose a new approach that allows for feedback at more critical and relevant junctures in the next 90 days. This will be a transparent process that includes your voices.
- As the WMF, we need to improve the process for managing changes that
impact all users. That includes the MediaWiki: namespace. For WMF to fulfill its role of leading consistent improvements to the user experience across Wikimedia projects, we need to be able to review code and manage deployments. This can be done in partnership with trusted volunteers, but WMF needs to be able to make an ultimate determination after receiving community feedback regarding production changes that impact all users.
- We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
and enter constructive, open-ended conversations about the way forward, provided we can mutually agree to do so on the basis of the current consistent configuration -- for now. We would like to request a moratorium on any attempts to disable the feature during this conflict resolution process. The goal would be to make a final, cross-wiki determination regarding this specific feature, in partnership with the community, within at most 90 days.
With regard to the German Wikipedia situation, we’d like to know if stewards want to at all be involved in this process: In a situation like this, it can be helpful to have a third party support the conversation. Stewards are accountable to "valid community consensus within the bounds of the Foundation's goals" [3], which seems to be precisely the intersection of concerns at issue here. We would like to suggest an IRC meeting with stewards ASAP to talk about the specific question of stewards’ involvement, if any. If stewards prefer not to be involved, we understand, but it's probably a good idea to have a sync-up conversation regardless.
I hope we can move forward in good faith from here, and find better ways to work together. As Lila has expressed, we believe there is a need for a clear understanding of our role. It is as follows:
Managing software development, site configuration and deployment is a core WMF responsibility. The community leads in the development of content; the Wikimedia Foundation leads in the development of technology.
Because these processes are deeply interdependent, we need to develop better protocols for timely feedback and resolution of disagreements. At the same time Lila’s and the Board’s statements make it very clear that the WMF will not accept RfCs or votes as the sole determining factor in global software deployments.
This means that technology and UX changes should not be decided by vote or poll and then disabled at-will: where we disagree, we need to talk to each other (and yes, that means a more judicious application of RESOLVED WONTFIX on our end, as well!). We need to ensure a process where the community voice is heard earlier at critical junctions in the product development. All of this is consistent with the principle of "shared power" articulated in the Guiding Principles [4] approved by the Board of Trustees.
At the same time, as noted above and earlier, the superprotection feature should be replaced with a better mechanism for code review and deployment in the MediaWiki: namespace. This is discussed in [5] and ideas and suggestions are welcome. Let’s be upfront about control structures for production changes to avoid misunderstandings and ambiguity in the future.
We are exploring options on how to improve dispute resolution mechanisms -- whether it’s e.g. a standing working group or a better protocol for responding to RfCs and engaging in discussions. We've started a brainstorming page, here, which we hope will usefully inform the process of conflict resolution regarding German Wikipedia, as well, so we can arrive at a more concrete conflict resolution process soon. Your thoughts/suggestions are welcome, so we can (in NPOV style) look at different possibilities (e.g. workgroups, committees, votes, surveys) that have been discussed in the past: https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
We’re absolutely not saying that WMF simply wants to be able to enforce its decisions: we completely understand there need to be mechanisms for the community to influence decisions and outcomes at all stages of the development and release of software. We need to arrive at this process together.
Again, we are sorry that this escalation occurred - and we hope we can move forward constructively from here.
Sincerely,
Erik
[1] https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbild...
[2] https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&am...
[3] https://meta.wikimedia.org/wiki/Stewards_policy
[4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shar...
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
-- Erik Möller VP of Engineering and Product Development, 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
Legal position:
I have seen it claimed by legal and repeated here by Erik that the "reasonableness" criteria means that we do not have to worry about the CCBYSA-3.0 clause that says all copyright holders need equal attribution. This is simply not so:
"The credit required by this Section 4(c) may be implemented *in any reasonable manner; provided, however, that *in the case of a Adaptation or Collection,* at a minimum such credit will appear*, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and* in a manner at least as prominent as the credits for the other contributing authors*."
There is no wriggle room here. * provided however that* means the following is compulsory, and not subject to the lenience of the previous phraseology.
On 31 August 2014 16:59, Yann Forget yannfo@gmail.com wrote:
Hi all,
Thank you Erik for your mail. It shows that the WMF is willing to discuss rather than to impose its solution.
I am really shocked that the dispute reaches that level of confrontation, and although some community members have a hard stance, this is largely due to WMF actions, specially the creation of the "superprotect" right. This is the worst possible step the WMF could make to find a solution for this issue.
Initially I was quite neutral about the MediaWiever, but I became increasingly skeptical. IMO it is hardly a priority, even for readers. Even if I am a long term contributor of Wikimedia projects, I am also a heavy reader of Wikipedia. I think that if a feature is refused in masse for the most active contributors, there is something wrong either in the feature itself, or in the way it is proposed to the projects. The WMF can certainly bring useful new additions in term of software development, but the implementation has to be done in a partnership with volunteer contributors. I cannot understand that the WMF in spite of its multi-million dollars budget is not able to convince volunteer contributors that the new feature is beneficial to the projects, either because it is technically very good, or that even with some shortcomings, it would improve the reading experience.
I am quite willing to test beta software, and I think there is no urgency to impose the MediaWiever now to everybody. I could be done after some time, when all issues have been sorted out. In term of media management, the most urgent and important thing is to fix the UploadWizard. Viewing images with Mediawiki may not be optimal, but it is not broken. The UploadWizard is broken.
Regards,
Yann
2014-08-20 0:42 GMT+05:30 Erik Moeller erik@wikimedia.org:
Hi folks,
This is a response to Martin's note here:
https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
.. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward.
I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it.
I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page.
Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a "better hack" to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint.
Our processes clearly need to be improved to avoid these situations in the future. We recognize that simply rejecting a community request rather than resolving a conflict together is not the right answer. We’ve been listening to feedback, and we’ve come to the following conclusions:
- We intend to undertake a review of our present processes immediately
and propose a new approach that allows for feedback at more critical and relevant junctures in the next 90 days. This will be a transparent process that includes your voices.
- As the WMF, we need to improve the process for managing changes that
impact all users. That includes the MediaWiki: namespace. For WMF to fulfill its role of leading consistent improvements to the user experience across Wikimedia projects, we need to be able to review code and manage deployments. This can be done in partnership with trusted volunteers, but WMF needs to be able to make an ultimate determination after receiving community feedback regarding production changes that impact all users.
- We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
and enter constructive, open-ended conversations about the way forward, provided we can mutually agree to do so on the basis of the current consistent configuration -- for now. We would like to request a moratorium on any attempts to disable the feature during this conflict resolution process. The goal would be to make a final, cross-wiki determination regarding this specific feature, in partnership with the community, within at most 90 days.
With regard to the German Wikipedia situation, we’d like to know if stewards want to at all be involved in this process: In a situation like this, it can be helpful to have a third party support the conversation. Stewards are accountable to "valid community consensus within the bounds of the Foundation's goals" [3], which seems to be precisely the intersection of concerns at issue here. We would like to suggest an IRC meeting with stewards ASAP to talk about the specific question of stewards’ involvement, if any. If stewards prefer not to be involved, we understand, but it's probably a good idea to have a sync-up conversation regardless.
I hope we can move forward in good faith from here, and find better ways to work together. As Lila has expressed, we believe there is a need for a clear understanding of our role. It is as follows:
Managing software development, site configuration and deployment is a core WMF responsibility. The community leads in the development of content; the Wikimedia Foundation leads in the development of technology.
Because these processes are deeply interdependent, we need to develop better protocols for timely feedback and resolution of disagreements. At the same time Lila’s and the Board’s statements make it very clear that the WMF will not accept RfCs or votes as the sole determining factor in global software deployments.
This means that technology and UX changes should not be decided by vote or poll and then disabled at-will: where we disagree, we need to talk to each other (and yes, that means a more judicious application of RESOLVED WONTFIX on our end, as well!). We need to ensure a process where the community voice is heard earlier at critical junctions in the product development. All of this is consistent with the principle of "shared power" articulated in the Guiding Principles [4] approved by the Board of Trustees.
At the same time, as noted above and earlier, the superprotection feature should be replaced with a better mechanism for code review and deployment in the MediaWiki: namespace. This is discussed in [5] and ideas and suggestions are welcome. Let’s be upfront about control structures for production changes to avoid misunderstandings and ambiguity in the future.
We are exploring options on how to improve dispute resolution mechanisms -- whether it’s e.g. a standing working group or a better protocol for responding to RfCs and engaging in discussions. We've started a brainstorming page, here, which we hope will usefully inform the process of conflict resolution regarding German Wikipedia, as well, so we can arrive at a more concrete conflict resolution process soon. Your thoughts/suggestions are welcome, so we can (in NPOV style) look at different possibilities (e.g. workgroups, committees, votes, surveys) that have been discussed in the past:
https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
We’re absolutely not saying that WMF simply wants to be able to enforce its decisions: we completely understand there need to be mechanisms for the community to influence decisions and outcomes at all stages of the development and release of software. We need to arrive at this process together.
Again, we are sorry that this escalation occurred - and we hope we can move forward constructively from here.
Sincerely,
Erik
[1]
https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbild...
[2]
https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&am...
[3] https://meta.wikimedia.org/wiki/Stewards_policy
[4]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shar...
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
-- Erik Möller VP of Engineering and Product Development, 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
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
Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for the projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead of feuding, and I'm getting MediaViewer issue fatigue.
WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make global decisions on a consensus basis.
Pine
On Aug 31, 2014 11:46 PM, "Pine W" wiki.pine@gmail.com wrote:
Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for the projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead
of
feuding, and I'm getting MediaViewer issue fatigue.
WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make
global
decisions on a consensus basis.
Pine
I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different projects, and frankly, I'm not buying it, unless the setting is intended to be removed completely.
Could someone explain to me how having a different default state for the setting has much, or any, impact?
- Martijn
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, The argument is not at all about the MediaViewer. It is only the latest flash point. Consequently the notion of how hard it is to set a default on or off is not relevant really.
When you read the Wikipedia Signpost you read about one of the major German players and it is found necessary to mention that his "tools" environment was ended and it became WMF labs. For me it gives the impression of sour grapes and a sense of failure because volunteers do not decide the agenda and feel angry/frustrated about that.
Consequently my conclusion that it is not about the MediaViewer at all. The next thing that comes along will be the next flash point. This is because it is emotions that speak and not arguments. Thanks, GerardM
On 1 September 2014 08:11, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Aug 31, 2014 11:46 PM, "Pine W" wiki.pine@gmail.com wrote:
Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for
the
projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead
of
feuding, and I'm getting MediaViewer issue fatigue.
WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make
global
decisions on a consensus basis.
Pine
I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different projects, and frankly, I'm not buying it, unless the setting is intended to be removed completely.
Could someone explain to me how having a different default state for the setting has much, or any, impact?
- Martijn
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
The difficulty of working with multiple configurations is one of WMF's main points, along with its opinion that readers prefer MV and that WMF should prioritize what WMF feels the readers want. WMF also is making a point of claiming soveriegnty over software configuration.
Meanwhile, many volunteers seem to view readership numbers as adequate with the status quo, do not believe that MV adds value, disagree with the design of Media Viewer, and are angered by WMF's undemocratic conduct and arrogant comments.
This kind of situation is unlikely to have a happy ending without some concessions and mediation.
Pine On Aug 31, 2014 11:32 PM, "Gerard Meijssen" gerard.meijssen@gmail.com wrote:
Hoi, The argument is not at all about the MediaViewer. It is only the latest flash point. Consequently the notion of how hard it is to set a default on or off is not relevant really.
When you read the Wikipedia Signpost you read about one of the major German players and it is found necessary to mention that his "tools" environment was ended and it became WMF labs. For me it gives the impression of sour grapes and a sense of failure because volunteers do not decide the agenda and feel angry/frustrated about that.
Consequently my conclusion that it is not about the MediaViewer at all. The next thing that comes along will be the next flash point. This is because it is emotions that speak and not arguments. Thanks, GerardM
On 1 September 2014 08:11, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Aug 31, 2014 11:46 PM, "Pine W" wiki.pine@gmail.com wrote:
Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for
the
projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work
instead
of
feuding, and I'm getting MediaViewer issue fatigue.
WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of
site
configurations is impractical for site maintainability and development
of
new features. The Technical Committee would be in a good position to make
global
decisions on a consensus basis.
Pine
I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different
projects,
and frankly, I'm not buying it, unless the setting is intended to be removed completely.
Could someone explain to me how having a different default state for the setting has much, or any, impact?
- Martijn
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
Hoi, Dear Pine. I do not care a fig about what "some users" think. You either support their view or you do not. When they consider that the current number of readers is adequate, I want to appreciate what they think those numbers are, what the trends are and how it is possible that their opinion is so starkly different from the ones I know about. Readership is down on computers and the current numbers are only supported because of tablets and mobiles. The same thing can be said about new editors; they are mainly arriving from mobiles and tablets.
Even "old timers" like myself loudly HATE the old crappy interface. So I am really displeased that you voice what "some users" think; as far as I am concerned it is "weasel talk". You either support the voices of "some users" or you do not. When you do, say so and argue. Do not let it hang in the air as if it has nothing to do with you.
Pine I know you know about research.. You know the numbers, you know how to get them where to ask. You do not have an excuse. Thanks, GerardM
On 1 September 2014 09:34, Pine W wiki.pine@gmail.com wrote:
The difficulty of working with multiple configurations is one of WMF's main points, along with its opinion that readers prefer MV and that WMF should prioritize what WMF feels the readers want. WMF also is making a point of claiming soveriegnty over software configuration.
Meanwhile, many volunteers seem to view readership numbers as adequate with the status quo, do not believe that MV adds value, disagree with the design of Media Viewer, and are angered by WMF's undemocratic conduct and arrogant comments.
This kind of situation is unlikely to have a happy ending without some concessions and mediation.
Pine On Aug 31, 2014 11:32 PM, "Gerard Meijssen" gerard.meijssen@gmail.com wrote:
Hoi, The argument is not at all about the MediaViewer. It is only the latest flash point. Consequently the notion of how hard it is to set a default
on
or off is not relevant really.
When you read the Wikipedia Signpost you read about one of the major
German
players and it is found necessary to mention that his "tools" environment was ended and it became WMF labs. For me it gives the impression of sour grapes and a sense of failure because volunteers do not decide the agenda and feel angry/frustrated about that.
Consequently my conclusion that it is not about the MediaViewer at all.
The
next thing that comes along will be the next flash point. This is because it is emotions that speak and not arguments. Thanks, GerardM
On 1 September 2014 08:11, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Aug 31, 2014 11:46 PM, "Pine W" wiki.pine@gmail.com wrote:
Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative
for
the
projects. Also, the amount of emotional hostility that this situation involves
is
disheartening. Personally, I would like to see us building on each other's work
instead
of
feuding, and I'm getting MediaViewer issue fatigue.
WMF's principal argument against letting projects make local
decisions
about configurations of MediaViewer seems to be that having a multitude of
site
configurations is impractical for site maintainability and
development
of
new features. The Technical Committee would be in a good position to make
global
decisions on a consensus basis.
Pine
I've heard the argument that it is difficult to maintain and develop
for
having different default states of this setting across different
projects,
and frankly, I'm not buying it, unless the setting is intended to be removed completely.
Could someone explain to me how having a different default state for
the
setting has much, or any, impact?
- Martijn
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
I think you've hit the nail on the head here. It's not about MediaViewer at all, it's about two things:
#1: The frustration of some volunteers that they feel their views are not being adequately considered in major deployments of new software. #2: A lack of confidence and faith in the WMF Engineering team to deliver quality software.
The second is the more dangerous one at this point. After the catastrophic aborted launch of the Visual Editor, complete with numerous bugs that should have been picked up in even a cursory unit testing scheme or regression testing scheme prior to being deployed to a productive environment, there's not a good deal of faith left. The technical problems with MediaViewer were not as serious, but since a significant portion of the power user base was expecting a failure, they jumped on the flaws that it did have, and here we are. To be honest, if Erik were to turn water into wine at this point, people would still complain, and loudly, that he had provided them with red when they wanted white.
I'm not sure that the solutions that have been offered; a new deployment process, or a tech council, are going to be sufficient to correct the real problem, which at this point is largely one of perception. Similarly, I don't think that the WMF adopting a complete hands-off approach as some seem to be demanding is going to lead to anything other than stagnation as individual communities squabble indecisively over what changes should be made. I do know that if it's not fixed, that pretty much every major deployment of new features is going to follow this same pattern, which is obviously highly undesirable.
What I'd suggest is that we leave the "emotional hostility" at the door and try to be reasonable. Neither side is going to get exactly what they want, and that is to be expected. To be honest, some of the invective that has been directed at Foundation staff has been completely over the top; phrases like "Taliban diplomacy" or honest-to-god comparisons to the Nazis don't move us towards a solution or make one seem like someone that can be intelligently reasoned with, they only harden feelings on both sides and make a suitable arrangement being found less likely. No employee should be made to receive that sort of harassment in the course of their job, no matter how much you disagree with them.
Cheers, Craig Franklin
On 1 September 2014 16:31, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, The argument is not at all about the MediaViewer. It is only the latest flash point. Consequently the notion of how hard it is to set a default on or off is not relevant really.
When you read the Wikipedia Signpost you read about one of the major German players and it is found necessary to mention that his "tools" environment was ended and it became WMF labs. For me it gives the impression of sour grapes and a sense of failure because volunteers do not decide the agenda and feel angry/frustrated about that.
Consequently my conclusion that it is not about the MediaViewer at all. The next thing that comes along will be the next flash point. This is because it is emotions that speak and not arguments. Thanks, GerardM
On 1 September 2014 08:11, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Aug 31, 2014 11:46 PM, "Pine W" wiki.pine@gmail.com wrote:
Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for
the
projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work
instead
of
feuding, and I'm getting MediaViewer issue fatigue.
WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of
site
configurations is impractical for site maintainability and development
of
new features. The Technical Committee would be in a good position to make
global
decisions on a consensus basis.
Pine
I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different
projects,
and frankly, I'm not buying it, unless the setting is intended to be removed completely.
Could someone explain to me how having a different default state for the setting has much, or any, impact?
- Martijn
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
Warning, tl;dr rant below in which live my personal opinion.
On 09/01/2014 08:00 AM, Craig Franklin wrote:
fter the catastrophic aborted launch of the Visual Editor, complete with numerous bugs that should have been picked up in even a cursory unit testing scheme or regression testing scheme prior to being deployed to a productive environment, there's not a good deal of faith left.
That /was/ a bad botch; and (IMO) the reason why that happened is that someone set a hard deploy date that should never have been set in stone and then held to it even though VE was clearly not ready. (It is *now* at a point with rollout would have been plausible).
Clearly nobody at WMF Engineering is going to do *that* again.
But I also don't think that was causative in any way; the tension between WMF holding the reins to the servers and (part of) the communities was the same years before that. ACCTRIAL anyone?
The fundamental issue is that the WMF is attempting to provide some direction, and the communities do not want any (for various and divergent reasons).
I side with the WMF in this; not because they sign my paycheck (I'm in Ops - I have zero to do with dev work) but because I've been a Wikipedian for >10 years and I *see* that the communities have no capacity for change - or that what little change manages to gather micro-consensus is local and often shortsighted. The projects are directionless, and it shows in the increasing stagnation and calcification.
Are all the attempts by the WMF at providing direction successes? Not even close. Some of the things they tried ranged from merely misguided to downright daft (also IMO, obviously).
The process *does* need community engagement. That'd seriously increases the value of what (and how) the WMF does things, and likely reduce the number of bad ideas from the outset.
But the community engagement it needs is one that is done in good faith; something which I have yet to see more than exceptions here and there. It also needs fewer reactionnary hotheads. Editing sucks. Reading is lacking. Most of the tooling is crap. That X editors have gotten used to it and have implemented piles of workarounds doesn't justify keeping the old shit around.
MV is a perfect example. 99% of the problems it objectively has (we ignore here matters of taste) derive from the difficulty of parsing the multitude overcomplicated templates living on File: pages to work around the fact that a wikitext page is complete and utter crap at storing metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. The *correct* solution is to fix the damn image pages, not to remove MV.
How is it that the old saying goes? "'We've always done things this way' is the most dangerous statement in any language?"
-- Marc
On 01/09/2014, Marc A. Pelletier marc@uberbox.org wrote: ...
metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. The *correct* solution is to fix the damn image pages, not to remove MV.
...
So, can you link me to a positive proposal to do the elemental foundation of this, and point to a realistic (and Foundation supported) proposal to the community to standardize licence templates on Commons?
Do this and you are most of the way there.
As someone who has uploaded 400,000 images to Commons with a variety of licences, I would welcome this proposal rather than doing it the wrong way around. Right now a rationale of blaming underpinning infrastructure not being ready for MV, after rolling it out, looks like setting your house on fire in order to give your husband sufficient motivation to check the smoke alarm.
Fae
On Mon, Sep 1, 2014 at 11:44 AM, Fæ faewik@gmail.com wrote:
On 01/09/2014, Marc A. Pelletier marc@uberbox.org wrote: ...
metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. The *correct* solution is to fix the damn image pages, not to remove MV.
...
So, can you link me to a positive proposal to do the elemental foundation of this, and point to a realistic (and Foundation supported) proposal to the community to standardize licence templates on Commons?
More than that, we should actually have the license data (and other stuff like attribution and descriptions) in a Wikidata-like structure instead of messing with parsing templates at all. The page for that is https://commons.wikimedia.org/wiki/Commons:Structured_data. Please do participate in that process.
That really should have been done first instead of the CommonsMetadata extension, in my personal opinion.
On Mon, Sep 1, 2014 at 9:10 AM, Marc A. Pelletier marc@uberbox.org wrote:
Warning, tl;dr rant below in which live my personal opinion.
On 09/01/2014 08:00 AM, Craig Franklin wrote:
fter the catastrophic aborted launch of the Visual Editor, complete with numerous bugs that should have been picked up in even a cursory unit testing scheme or regression testing scheme prior to being deployed to a productive environment, there's not a good deal of faith left.
That /was/ a bad botch; and (IMO) the reason why that happened is that someone set a hard deploy date that should never have been set in stone and then held to it even though VE was clearly not ready. (It is *now* at a point with rollout would have been plausible).
Clearly nobody at WMF Engineering is going to do *that* again.
We've heard that before.
But I also don't think that was causative in any way; the tension between WMF holding the reins to the servers and (part of) the communities was the same years before that. ACCTRIAL anyone?
Sure, for reasons I'll get to below. That contradicts the rest of what you said here.
The fundamental issue is that the WMF is attempting to provide some direction, and the communities do not want any (for various and divergent reasons).
I don't think it's that the communities don't want any direction. It's that large, open projects historically managed by their volunteers are not amenable to top-down, authoritarian direction. All that will do is start fights, to the detriment of everyone and especially to the detriment of said projects. None of us are out a paycheck if we scale back our activity or walk away in disgust.
I side with the WMF in this; not because they sign my paycheck (I'm in Ops - I have zero to do with dev work) but because I've been a Wikipedian for >10 years and I *see* that the communities have no capacity for change - or that what little change manages to gather micro-consensus is local and often shortsighted. The projects are directionless, and it shows in the increasing stagnation and calcification.
That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said "Nah, rather not." When treated that way, do you think the community has much appetite to continue discussing necessary changes when the last time was a significant effort ultimately ending in futility, not because of a failure on the community's part, but because of WMF's refusal to listen?
Are all the attempts by the WMF at providing direction successes? Not even close. Some of the things they tried ranged from merely misguided to downright daft (also IMO, obviously).
The process *does* need community engagement. That'd seriously increases the value of what (and how) the WMF does things, and likely reduce the number of bad ideas from the outset.
As above, that's not going to happen if that engagement continues to result in brushoffs. Look at Flow. One overwhelming message is "We don't want it at all" (and that demands real consideration, not dismissive comments about "resistance to change" and "power users"), but when asked what could at least make it better, the answers of "Preserve ability for anyone to refactor posts as needed, don't restrict to admins" and "Don't limit indentation" have fallen on deaf ears. Again, if there's no one listening, people are not going to continue talking to what by all appearances is a brick wall.
But the community engagement it needs is one that is done in good faith; something which I have yet to see more than exceptions here and there. It also needs fewer reactionnary hotheads. Editing sucks. Reading is lacking. Most of the tooling is crap. That X editors have gotten used to it and have implemented piles of workarounds doesn't justify keeping the old shit around.
Maybe. I don't really think it's crap. Reflinks wasn't crap. That doesn't mean we can't do better, but we need to do actually better, not just "We need to do something, this is something, so do it!"
Regardless, same again: That needs to be met with good faith on the other side, to stop just plowing ahead when everyone's saying "WAIT, there's serious problems here!". Engagement doesn't work if it's the classic "suggestions box" positioned directly over a garbage can.
MV is a perfect example. 99% of the problems it objectively has (we ignore here matters of taste) derive from the difficulty of parsing the multitude overcomplicated templates living on File: pages to work around the fact that a wikitext page is complete and utter crap at storing metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. The *correct* solution is to fix the damn image pages, not to remove MV.
How is it that the old saying goes? "'We've always done things this way' is the most dangerous statement in any language?"
Change for the sake of change can easily be as dangerous. I think most agree that some changes are necessary. As above, one of the historical blowups was when the en.wp community came to clear consensus, asked for a change, and just got a dismissive WONTFIX. If you want to drive engagement, show real willingness to respond to that engagement with actions and real changes, not yet another promise to do better next time, we really really mean it now. Sometimes, that might mean doing things the person doing them doesn't personally agree with.
-- Marc
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 09/01/2014 11:45 AM, Todd Allen wrote:
On Mon, Sep 1, 2014 at 9:10 AM, Marc A. Pelletier marc@uberbox.org wrote: We've heard that before.
Oh, I'm pretty damn sure that the "stick to the timeline" idea isn't going to get traction ever again. :-) But yeah in general recognizing an error is not, in itself, proof against repeating it. Errare humanum est.
I don't think it's that the communities don't want any direction. It's that large, open projects historically managed by their volunteers are not amenable to top-down, authoritarian direction. All that will do is start fights, to the detriment of everyone and especially to the detriment of said projects. None of us are out a paycheck if we scale back our activity or walk away in disgust.
There's that, but there's also the (unavoidable) issue that Wikipedia was revolutionnary, so it attracted a great deal of people who had little to no desire to abide "The Man". The problem is we /are/ "The Man" now.
That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said "Nah, rather not."
That, IMO, is an example of what I call a shortsighted change. It *might* have been a good local change, in the end, but it nevertheless was a fundamental dent in the project values in order to solve an extremely local problem. If I were the Foundation back then I probably also would have refused to proceed without Licence-change-level consensus and a long consultation process - at the very least.
Like or not, the Foundation is in the odd position of being the guardian of the "Big Picture"; local projects are exactly that - local. What may be a good local change may turn out to be globally disastrous (because divergence, precedent, etc). But that's getting into a discussion of federalism as a concept (and whether the projects are de facto federated) which may be interesting in itself but is way waaaay off-topic. :-)
Regardless, same again: That needs to be met with good faith on the other side, to stop just plowing ahead when everyone's saying "WAIT, there's serious problems here!". Engagement doesn't work if it's the classic "suggestions box" positioned directly over a garbage can.
I don't think that's true. At least, from my privileged position (where I see much of the "internal" dev chatter from the sidelines) that has never seemed to be the case.
Change for the sake of change can easily be as dangerous.
That's true, to a point, but I can say with quite a bit of confidence that nobody at the Foundation ever said "Let's change this" without a solid "This seems to be an improvement because" behind it (or, at the very least "Y is demonstrably broken, we don't know what's the best way to fix it, let's try Z".
They may be *wrong*; but every bit of development I've seen is based on a rational desire to improve and from reasonable assumptions about what will be an improvement.
And, honestly, it's better to try and possibly fail to fix than it is to avoid trying and definitely stay broken.
-- Marc
On Sep 1, 2014, at 8:45 AM, Todd Allen toddmallen@gmail.com wrote:
That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said "Nah, rather not."
That's... Not exactly what I remember happening there. What I remember was that a pretty good number (~500) of enwiki community members came together and agreed on a problem, and one plan for how to fix it and asked the WMF to implement it. The WMF evaluated it, and saw a threat to a basic project value. WMF then asked "what's the problem you're actually trying to solve?", and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since.
______________________ Philippe Beaudette Director, Community Advocacy
On Sep 1, 2014 3:21 PM, "Philippe Beaudette" pbeaudette@wikimedia.org wrote:
On Sep 1, 2014, at 8:45 AM, Todd Allen toddmallen@gmail.com wrote:
That's contradicted by, among other things, ACTRIAL as mentioned above.
The
en.wp community came to a clear consensus for a major change, and the
WMF
shrugged and said "Nah, rather not."
That's... Not exactly what I remember happening there. What I remember
was that a pretty good number (~500) of enwiki community members came together and agreed on a problem, and one plan for how to fix it and asked the WMF to implement it. The WMF evaluated it, and saw a threat to a basic project value. WMF then asked "what's the problem you're actually trying to solve?", and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since.
I don't agree with that assessment, but it's possible I'm missing some elements of the process. Philippe, any chance you could full in the summary with a few specifics, and maybe some links?
Pete
That's the issue I cited above. You haven't heard more complaints, because the complaint was pointless the first time and took a massive effort to produce.
The underlying issue isn't fixed. We're still drowning in crap and spam from people who never have the slightest intent of editing helpfully, and those who are newbies who genuinely want to help but need guidance get caught in the crossfire aimed at the vandals and spammers. It is relatively rare that when a genuinely new editor's first edit is a creation, it is the creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that they should do it.
So, consider that a complaint. The proposed fix didn't work, and most people at the time didn't figure it would work, but it was clearly the best we were going to get.
On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette <pbeaudette@wikimedia.org
wrote:
On Sep 1, 2014, at 8:45 AM, Todd Allen toddmallen@gmail.com wrote:
That's contradicted by, among other things, ACTRIAL as mentioned above.
The
en.wp community came to a clear consensus for a major change, and the WMF shrugged and said "Nah, rather not."
That's... Not exactly what I remember happening there. What I remember was that a pretty good number (~500) of enwiki community members came together and agreed on a problem, and one plan for how to fix it and asked the WMF to implement it. The WMF evaluated it, and saw a threat to a basic project value. WMF then asked "what's the problem you're actually trying to solve?", and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since.
Philippe Beaudette Director, Community Advocacy _______________________________________________ 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
This, to the best of my knowledge, represents the entirety of the WMF's response to ACTRIAL. To the extent that there was additional feedback given, it was not given at WP:ACTRIAL, nor any other venue I am aware of.
https://bugzilla.wikimedia.org/show_bug.cgi?id=30208
--Joe
On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen toddmallen@gmail.com wrote:
That's the issue I cited above. You haven't heard more complaints, because the complaint was pointless the first time and took a massive effort to produce.
The underlying issue isn't fixed. We're still drowning in crap and spam from people who never have the slightest intent of editing helpfully, and those who are newbies who genuinely want to help but need guidance get caught in the crossfire aimed at the vandals and spammers. It is relatively rare that when a genuinely new editor's first edit is a creation, it is the creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that they should do it.
So, consider that a complaint. The proposed fix didn't work, and most people at the time didn't figure it would work, but it was clearly the best we were going to get.
On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette < pbeaudette@wikimedia.org
wrote:
On Sep 1, 2014, at 8:45 AM, Todd Allen toddmallen@gmail.com wrote:
That's contradicted by, among other things, ACTRIAL as mentioned above.
The
en.wp community came to a clear consensus for a major change, and the
WMF
shrugged and said "Nah, rather not."
That's... Not exactly what I remember happening there. What I remember
was
that a pretty good number (~500) of enwiki community members came
together
and agreed on a problem, and one plan for how to fix it and asked the
WMF
to implement it. The WMF evaluated it, and saw a threat to a basic
project
value. WMF then asked "what's the problem you're actually trying to solve?", and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since.
Philippe Beaudette Director, Community Advocacy _______________________________________________ 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
Wasn't the creation of the DRAFT namespace at least in part a response to concerns raised at ACTRIAL, in particular new, poorly developed articles showing up in mainspace?
Risker/Anne
On 1 September 2014 19:08, Joe Decker joedecker@gmail.com wrote:
This, to the best of my knowledge, represents the entirety of the WMF's response to ACTRIAL. To the extent that there was additional feedback given, it was not given at WP:ACTRIAL, nor any other venue I am aware of.
https://bugzilla.wikimedia.org/show_bug.cgi?id=30208
--Joe
On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen toddmallen@gmail.com wrote:
That's the issue I cited above. You haven't heard more complaints,
because
the complaint was pointless the first time and took a massive effort to produce.
The underlying issue isn't fixed. We're still drowning in crap and spam from people who never have the slightest intent of editing helpfully, and those who are newbies who genuinely want to help but need guidance get caught in the crossfire aimed at the vandals and spammers. It is
relatively
rare that when a genuinely new editor's first edit is a creation, it is
the
creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that they should do it.
So, consider that a complaint. The proposed fix didn't work, and most people at the time didn't figure it would work, but it was clearly the
best
we were going to get.
On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette < pbeaudette@wikimedia.org
wrote:
On Sep 1, 2014, at 8:45 AM, Todd Allen toddmallen@gmail.com wrote:
That's contradicted by, among other things, ACTRIAL as mentioned
above.
The
en.wp community came to a clear consensus for a major change, and the
WMF
shrugged and said "Nah, rather not."
That's... Not exactly what I remember happening there. What I remember
was
that a pretty good number (~500) of enwiki community members came
together
and agreed on a problem, and one plan for how to fix it and asked the
WMF
to implement it. The WMF evaluated it, and saw a threat to a basic
project
value. WMF then asked "what's the problem you're actually trying to solve?", and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems
to
have worked out pretty well because I haven't heard a ton of complaints about that problem since.
Philippe Beaudette Director, Community Advocacy _______________________________________________ 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
-- Joe Decker www.joedecker.net _______________________________________________ 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 hope that's not the feature Philippe meant, but maybe. For my clients and students I think it's generally caused more confusion than it's solved, since now they have an additional layer of bureaucracy to navigate (AFC). Is there any data suggesting that's been a net improvement for new users?
Pete On Sep 1, 2014 4:38 PM, "Risker" risker.wp@gmail.com wrote:
Wasn't the creation of the DRAFT namespace at least in part a response to concerns raised at ACTRIAL, in particular new, poorly developed articles showing up in mainspace?
Risker/Anne
On 1 September 2014 19:08, Joe Decker joedecker@gmail.com wrote:
This, to the best of my knowledge, represents the entirety of the WMF's response to ACTRIAL. To the extent that there was additional feedback given, it was not given at WP:ACTRIAL, nor any other venue I am aware of.
https://bugzilla.wikimedia.org/show_bug.cgi?id=30208
--Joe
On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen toddmallen@gmail.com wrote:
That's the issue I cited above. You haven't heard more complaints,
because
the complaint was pointless the first time and took a massive effort to produce.
The underlying issue isn't fixed. We're still drowning in crap and spam from people who never have the slightest intent of editing helpfully,
and
those who are newbies who genuinely want to help but need guidance get caught in the crossfire aimed at the vandals and spammers. It is
relatively
rare that when a genuinely new editor's first edit is a creation, it is
the
creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that they should do it.
So, consider that a complaint. The proposed fix didn't work, and most people at the time didn't figure it would work, but it was clearly the
best
we were going to get.
On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette < pbeaudette@wikimedia.org
wrote:
On Sep 1, 2014, at 8:45 AM, Todd Allen toddmallen@gmail.com
wrote:
That's contradicted by, among other things, ACTRIAL as mentioned
above.
The
en.wp community came to a clear consensus for a major change, and
the
WMF
shrugged and said "Nah, rather not."
That's... Not exactly what I remember happening there. What I
remember
was
that a pretty good number (~500) of enwiki community members came
together
and agreed on a problem, and one plan for how to fix it and asked
the
WMF
to implement it. The WMF evaluated it, and saw a threat to a basic
project
value. WMF then asked "what's the problem you're actually trying to solve?", and proposed and built a set of tools to directly address
that
problem without compromising the core value of openness. And it seems
to
have worked out pretty well because I haven't heard a ton of
complaints
about that problem since.
Philippe Beaudette Director, Community Advocacy _______________________________________________ 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
-- Joe Decker www.joedecker.net _______________________________________________ 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
What is irritating about the ACTRIAL scenario, was that it was a well defined (6 month) test.
It might have worked, it might not have worked. But we would have known. We would have had solid comparators.
Most of what we do (WMF and community) has no control to establish whether it works.
To be clear, I am against preventing article creation by IPs let alone non-autoconfirmed users. But this trial might well have provided compelling evidence one way or the other.
The dismissal as a "we know better" was a bad thing, but not uncommon on Bugzilla.
On 2 September 2014 01:06, Pete Forsyth peteforsyth@gmail.com wrote:
I hope that's not the feature Philippe meant, but maybe. For my clients and students I think it's generally caused more confusion than it's solved, since now they have an additional layer of bureaucracy to navigate (AFC). Is there any data suggesting that's been a net improvement for new users?
Pete On Sep 1, 2014 4:38 PM, "Risker" risker.wp@gmail.com wrote:
Wasn't the creation of the DRAFT namespace at least in part a response to concerns raised at ACTRIAL, in particular new, poorly developed articles showing up in mainspace?
Risker/Anne
On 1 September 2014 19:08, Joe Decker joedecker@gmail.com wrote:
This, to the best of my knowledge, represents the entirety of the WMF's response to ACTRIAL. To the extent that there was additional feedback given, it was not given at WP:ACTRIAL, nor any other venue I am aware
of.
https://bugzilla.wikimedia.org/show_bug.cgi?id=30208
--Joe
On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen toddmallen@gmail.com
wrote:
That's the issue I cited above. You haven't heard more complaints,
because
the complaint was pointless the first time and took a massive effort
to
produce.
The underlying issue isn't fixed. We're still drowning in crap and
spam
from people who never have the slightest intent of editing helpfully,
and
those who are newbies who genuinely want to help but need guidance
get
caught in the crossfire aimed at the vandals and spammers. It is
relatively
rare that when a genuinely new editor's first edit is a creation, it
is
the
creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that
they
should do it.
So, consider that a complaint. The proposed fix didn't work, and most people at the time didn't figure it would work, but it was clearly
the
best
we were going to get.
On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette < pbeaudette@wikimedia.org
wrote:
On Sep 1, 2014, at 8:45 AM, Todd Allen toddmallen@gmail.com
wrote:
That's contradicted by, among other things, ACTRIAL as mentioned
above.
The
en.wp community came to a clear consensus for a major change, and
the
WMF
shrugged and said "Nah, rather not."
That's... Not exactly what I remember happening there. What I
remember
was
that a pretty good number (~500) of enwiki community members came
together
and agreed on a problem, and one plan for how to fix it and asked
the
WMF
to implement it. The WMF evaluated it, and saw a threat to a basic
project
value. WMF then asked "what's the problem you're actually trying to solve?", and proposed and built a set of tools to directly address
that
problem without compromising the core value of openness. And it
seems
to
have worked out pretty well because I haven't heard a ton of
complaints
about that problem since.
Philippe Beaudette Director, Community Advocacy _______________________________________________ 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
-- Joe Decker www.joedecker.net _______________________________________________ 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
Philippe, can you address what you were talking about here last fall -- was the draft feature, and the way it directed new contributors toward the Articles for Creation process, the thing you alluded to, that WMF did in response to ACTRIAL?
If so -- has there been any study of whether its intended outcomes panned out? If not -- could you outline what you meant by "[WMF] proposed and built a set of tools to directly address that problem without compromising the core value of openness"?
Pete [[User:Peteforsyth]]
On Mon, Sep 1, 2014 at 5:06 PM, Pete Forsyth peteforsyth@gmail.com wrote:
I hope that's not the feature Philippe meant, but maybe. For my clients and students I think it's generally caused more confusion than it's solved, since now they have an additional layer of bureaucracy to navigate (AFC). Is there any data suggesting that's been a net improvement for new users?
Pete On Sep 1, 2014 4:38 PM, "Risker" risker.wp@gmail.com wrote:
Wasn't the creation of the DRAFT namespace at least in part a response to concerns raised at ACTRIAL, in particular new, poorly developed articles showing up in mainspace?
Risker/Anne
On 1 September 2014 19:08, Joe Decker joedecker@gmail.com wrote:
This, to the best of my knowledge, represents the entirety of the WMF's response to ACTRIAL. To the extent that there was additional feedback given, it was not given at WP:ACTRIAL, nor any other venue I am aware
of.
https://bugzilla.wikimedia.org/show_bug.cgi?id=30208
--Joe
On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen toddmallen@gmail.com
wrote:
That's the issue I cited above. You haven't heard more complaints,
because
the complaint was pointless the first time and took a massive effort
to
produce.
The underlying issue isn't fixed. We're still drowning in crap and
spam
from people who never have the slightest intent of editing helpfully,
and
those who are newbies who genuinely want to help but need guidance get caught in the crossfire aimed at the vandals and spammers. It is
relatively
rare that when a genuinely new editor's first edit is a creation, it
is
the
creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that they should do it.
So, consider that a complaint. The proposed fix didn't work, and most people at the time didn't figure it would work, but it was clearly the
best
we were going to get.
On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette < pbeaudette@wikimedia.org
wrote:
On Sep 1, 2014, at 8:45 AM, Todd Allen toddmallen@gmail.com
wrote:
That's contradicted by, among other things, ACTRIAL as mentioned
above.
The
en.wp community came to a clear consensus for a major change, and
the
WMF
shrugged and said "Nah, rather not."
That's... Not exactly what I remember happening there. What I
remember
was
that a pretty good number (~500) of enwiki community members came
together
and agreed on a problem, and one plan for how to fix it and asked
the
WMF
to implement it. The WMF evaluated it, and saw a threat to a basic
project
value. WMF then asked "what's the problem you're actually trying to solve?", and proposed and built a set of tools to directly address
that
problem without compromising the core value of openness. And it
seems
to
have worked out pretty well because I haven't heard a ton of
complaints
about that problem since.
Philippe Beaudette Director, Community Advocacy _______________________________________________ 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
-- Joe Decker www.joedecker.net _______________________________________________ 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 https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hi Pete,
Philippe is on vacation, so I'm forwarding this to Rachel.
Pine On Apr 22, 2015 11:59 PM, "Pete Forsyth" peteforsyth@gmail.com wrote:
Philippe, can you address what you were talking about here last fall -- was the draft feature, and the way it directed new contributors toward the Articles for Creation process, the thing you alluded to, that WMF did in response to ACTRIAL?
If so -- has there been any study of whether its intended outcomes panned out? If not -- could you outline what you meant by "[WMF] proposed and built a set of tools to directly address that problem without compromising the core value of openness"?
Pete [[User:Peteforsyth]]
On Mon, Sep 1, 2014 at 5:06 PM, Pete Forsyth peteforsyth@gmail.com wrote:
I hope that's not the feature Philippe meant, but maybe. For my clients and students I think it's generally caused more confusion than it's
solved,
since now they have an additional layer of bureaucracy to navigate (AFC). Is there any data suggesting that's been a net improvement for new users?
Pete On Sep 1, 2014 4:38 PM, "Risker" risker.wp@gmail.com wrote:
Wasn't the creation of the DRAFT namespace at least in part a response
to
concerns raised at ACTRIAL, in particular new, poorly developed articles showing up in mainspace?
Risker/Anne
On 1 September 2014 19:08, Joe Decker joedecker@gmail.com wrote:
This, to the best of my knowledge, represents the entirety of the
WMF's
response to ACTRIAL. To the extent that there was additional feedback given, it was not given at WP:ACTRIAL, nor any other venue I am aware
of.
https://bugzilla.wikimedia.org/show_bug.cgi?id=30208
--Joe
On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen toddmallen@gmail.com
wrote:
That's the issue I cited above. You haven't heard more complaints,
because
the complaint was pointless the first time and took a massive effort
to
produce.
The underlying issue isn't fixed. We're still drowning in crap and
spam
from people who never have the slightest intent of editing
helpfully,
and
those who are newbies who genuinely want to help but need guidance
get
caught in the crossfire aimed at the vandals and spammers. It is
relatively
rare that when a genuinely new editor's first edit is a creation, it
is
the
creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that
they
should do it.
So, consider that a complaint. The proposed fix didn't work, and
most
people at the time didn't figure it would work, but it was clearly
the
best
we were going to get.
On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette < pbeaudette@wikimedia.org
wrote:
> On Sep 1, 2014, at 8:45 AM, Todd Allen toddmallen@gmail.com
wrote:
> > That's contradicted by, among other things, ACTRIAL as mentioned
above.
The > en.wp community came to a clear consensus for a major change,
and
the
WMF
> shrugged and said "Nah, rather not."
That's... Not exactly what I remember happening there. What I
remember
was
that a pretty good number (~500) of enwiki community members came
together
and agreed on a problem, and one plan for how to fix it and asked
the
WMF
to implement it. The WMF evaluated it, and saw a threat to a basic
project
value. WMF then asked "what's the problem you're actually trying
to
solve?", and proposed and built a set of tools to directly address
that
problem without compromising the core value of openness. And it
seems
to
have worked out pretty well because I haven't heard a ton of
complaints
about that problem since.
Philippe Beaudette Director, Community Advocacy _______________________________________________ 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>
-- Joe Decker www.joedecker.net _______________________________________________ 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 <
https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wi...
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
I don't know that there is a next step. The WMF has clearly indicated they will not budge on the solution that the high-level Wikipedia community says is needed. I have qualms myself about the way the community operates at times but covering ACTRAIL and New Page Patrol at the Signpost felt like an enormous and egregious slap across the face. I still see and feel the repercussions of these breaches of trust today.
On Thu, Apr 23, 2015 at 2:03 PM, Pine W wiki.pine@gmail.com wrote:
Hi Pete,
Philippe is on vacation, so I'm forwarding this to Rachel.
Pine On Apr 22, 2015 11:59 PM, "Pete Forsyth" peteforsyth@gmail.com wrote:
Philippe, can you address what you were talking about here last fall --
was
the draft feature, and the way it directed new contributors toward the Articles for Creation process, the thing you alluded to, that WMF did in response to ACTRIAL?
If so -- has there been any study of whether its intended outcomes panned out? If not -- could you outline what you meant by "[WMF] proposed and built a set of tools to directly address that problem without
compromising
the core value of openness"?
Pete [[User:Peteforsyth]]
On Mon, Sep 1, 2014 at 5:06 PM, Pete Forsyth peteforsyth@gmail.com wrote:
I hope that's not the feature Philippe meant, but maybe. For my clients and students I think it's generally caused more confusion than it's
solved,
since now they have an additional layer of bureaucracy to navigate
(AFC).
Is there any data suggesting that's been a net improvement for new
users?
Pete On Sep 1, 2014 4:38 PM, "Risker" risker.wp@gmail.com wrote:
Wasn't the creation of the DRAFT namespace at least in part a response
to
concerns raised at ACTRIAL, in particular new, poorly developed
articles
showing up in mainspace?
Risker/Anne
On 1 September 2014 19:08, Joe Decker joedecker@gmail.com wrote:
This, to the best of my knowledge, represents the entirety of the
WMF's
response to ACTRIAL. To the extent that there was additional
feedback
given, it was not given at WP:ACTRIAL, nor any other venue I am
aware
of.
https://bugzilla.wikimedia.org/show_bug.cgi?id=30208
--Joe
On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen toddmallen@gmail.com
wrote:
That's the issue I cited above. You haven't heard more complaints,
because
the complaint was pointless the first time and took a massive
effort
to
produce.
The underlying issue isn't fixed. We're still drowning in crap and
spam
from people who never have the slightest intent of editing
helpfully,
and
those who are newbies who genuinely want to help but need guidance
get
caught in the crossfire aimed at the vandals and spammers. It is
relatively
rare that when a genuinely new editor's first edit is a creation,
it
is
the
creation of an appropriate article on a workable subject, and
that's
normally more by dumb luck than them having actual knowledge that
they
should do it.
So, consider that a complaint. The proposed fix didn't work, and
most
people at the time didn't figure it would work, but it was clearly
the
best
we were going to get.
On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette < pbeaudette@wikimedia.org > wrote:
> > > > > On Sep 1, 2014, at 8:45 AM, Todd Allen toddmallen@gmail.com
wrote:
> > > > That's contradicted by, among other things, ACTRIAL as
mentioned
above.
> The > > en.wp community came to a clear consensus for a major change,
and
the
WMF > > shrugged and said "Nah, rather not." > > That's... Not exactly what I remember happening there. What I
remember
was > that a pretty good number (~500) of enwiki community members
came
together > and agreed on a problem, and one plan for how to fix it and
asked
the
WMF > to implement it. The WMF evaluated it, and saw a threat to a
basic
project > value. WMF then asked "what's the problem you're actually trying
to
> solve?", and proposed and built a set of tools to directly
address
that
> problem without compromising the core value of openness. And it
seems
to
> have worked out pretty well because I haven't heard a ton of
complaints
> about that problem since. > > ______________________ > Philippe Beaudette > Director, Community Advocacy > _______________________________________________ > 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>
-- Joe Decker www.joedecker.net _______________________________________________ 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 <
https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wi...
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
James Alexander Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.pine@gmail.com wrote:
Hi Pete,
Philippe is on vacation, so I'm forwarding this to Rachel.
Pine
He pops in every once in a while during his break but while he is away Maggie and I are splitting his work up (and this is, for better or worse, well before Rachel's time).
On Apr 22, 2015 11:59 PM, "Pete Forsyth" peteforsyth@gmail.com wrote:
Philippe, can you address what you were talking about here last fall --
was
the draft feature, and the way it directed new contributors toward the Articles for Creation process, the thing you alluded to, that WMF did in response to ACTRIAL?
If so -- has there been any study of whether its intended outcomes panned out? If not -- could you outline what you meant by "[WMF] proposed and built a set of tools to directly address that problem without
compromising
the core value of openness"?
Pete [[User:Peteforsyth]]
I do not believe he was talking about the Draft feature, which came later. I think he was referring to the Page Curation https://www.mediawiki.org/wiki/Page_Curation tool which I know for a fact was created in direct response to ACTRIAL because one of the big complaints was the difficulty with patrolling new pages. While I wasn't directly involved it was one of the first software products I remember (either as a community member or staff member) the Foundation trying to engage closely with the community throughout it's development to create something that would work well. I also think it was the first product with a Community Liaison (who, incidentally, had been the most active page patroller for multiple years before as a community member).
Sure, and from what I hear it helped, but it was no panacea, especially since it's a solution that still relies on a still-declining editor base. Not like turning the valves would be, and that's clearly not going to happen. Hence why I doubt there's much more room for improvement on this issue. New tech can only do so much to fix the problem.
On Thu, Apr 23, 2015 at 11:01 PM, James Alexander jalexander@wikimedia.org wrote:
James Alexander Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.pine@gmail.com wrote:
Hi Pete,
Philippe is on vacation, so I'm forwarding this to Rachel.
Pine
He pops in every once in a while during his break but while he is away Maggie and I are splitting his work up (and this is, for better or worse, well before Rachel's time).
On Apr 22, 2015 11:59 PM, "Pete Forsyth" peteforsyth@gmail.com wrote:
Philippe, can you address what you were talking about here last fall --
was
the draft feature, and the way it directed new contributors toward the Articles for Creation process, the thing you alluded to, that WMF did
in
response to ACTRIAL?
If so -- has there been any study of whether its intended outcomes
panned
out? If not -- could you outline what you meant by "[WMF] proposed and built a set of tools to directly address that problem without
compromising
the core value of openness"?
Pete [[User:Peteforsyth]]
I do not believe he was talking about the Draft feature, which came later. I think he was referring to the Page Curation https://www.mediawiki.org/wiki/Page_Curation tool which I know for a fact was created in direct response to ACTRIAL because one of the big complaints was the difficulty with patrolling new pages. While I wasn't directly involved it was one of the first software products I remember (either as a community member or staff member) the Foundation trying to engage closely with the community throughout it's development to create something that would work well. I also think it was the first product with a Community Liaison (who, incidentally, had been the most active page patroller for multiple years before as a community member). _______________________________________________ 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 agree with the statement "New tech can only do so much to fix the problem." Our retention rate for new editors was <1% the last time I checked. What we should do about that should probably be the subject of a different thread. We've had multiple discussions about vital statistics for the editor population on this mailing list, the Research mailing list, and the Gendergap mailing list, in addition to countless on-wiki discussions. I also hope that there will be discussions about this issue at the Wikimedia Conference. I personally wrote "Saving Wikipedia" as one of my interests in attending the conference, and that's not an exaggeration. We need to get out of long-term-decline mode.
Pine
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Thu, Apr 23, 2015 at 8:08 PM, Aleksey Bilogur aleksey.bilogur@gmail.com wrote:
Sure, and from what I hear it helped, but it was no panacea, especially since it's a solution that still relies on a still-declining editor base. Not like turning the valves would be, and that's clearly not going to happen. Hence why I doubt there's much more room for improvement on this issue. New tech can only do so much to fix the problem.
On Thu, Apr 23, 2015 at 11:01 PM, James Alexander < jalexander@wikimedia.org> wrote:
James Alexander Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.pine@gmail.com wrote:
Hi Pete,
Philippe is on vacation, so I'm forwarding this to Rachel.
Pine
He pops in every once in a while during his break but while he is away Maggie and I are splitting his work up (and this is, for better or worse, well before Rachel's time).
On Apr 22, 2015 11:59 PM, "Pete Forsyth" peteforsyth@gmail.com
wrote:
Philippe, can you address what you were talking about here last fall
--
was
the draft feature, and the way it directed new contributors toward
the
Articles for Creation process, the thing you alluded to, that WMF did
in
response to ACTRIAL?
If so -- has there been any study of whether its intended outcomes
panned
out? If not -- could you outline what you meant by "[WMF] proposed
and
built a set of tools to directly address that problem without
compromising
the core value of openness"?
Pete [[User:Peteforsyth]]
I do not believe he was talking about the Draft feature, which came
later.
I think he was referring to the Page Curation https://www.mediawiki.org/wiki/Page_Curation tool which I know for a fact was created in direct response to ACTRIAL because one of the big
complaints
was the difficulty with patrolling new pages. While I wasn't directly involved it was one of the first software products I remember (either as
a
community member or staff member) the Foundation trying to engage closely with the community throughout it's development to create something that would work well. I also think it was the first product with a Community Liaison (who, incidentally, had been the most active page patroller for multiple years before as a community member). _______________________________________________ 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 Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.pine@gmail.com wrote:
Philippe is on vacation, so I'm forwarding this to Rachel.
Thanks Pine. That's unfortunate, but maybe there is somebody (maybe Fabrice?) who can shed some light on the general thinking in the software development in this area. There have been several closely related things -- Article Creation Wizard, Draft: namespace, New Page Patrol software... -- and I see many references to an overall plan, but I've had difficulty finding a summary of that plan.
In the meantime, I've been trying to put the pieces together myself, and have gotten some good assistance from Nemo Bis and Aaron Halfaker -- see here: https://meta.wikimedia.org/wiki/Research_talk:Wikipedia_article_creation#Cut...
At this point, in addition to clarification from Philippe about which part he was referring to, the main thing I'm hoping to accomplish is basically a timeline of milestones, more or less like this (I have somewhat made up the data below for the sake of illustrating the format):
* January 1, 2004: AFC process created. [[Wikilink to tool]] [diff or mailing list for decision-making process] * February 1, 2011: RfC on English Wikipedia calls for new procedure [[wikilink to RfC]] [Bugzilla link for request] * June 1, 2011: Articles for Creation wizard launched [[Wikilink]] [discussion link] with these impacts on user experience: ** Impact 1 ** Impact 2 ** Impact 3... ...and so on.
Who at WMF would be best able to fill in the gaps in such a list? Or does the list already exist in a strategy document somewhere? I haven't been able to find it yet, but I'm still looking.
Pete [[User:Peteforsyth]]
Hi Pete,
James A. might be able to answer that, or know which project manager to ping.
AFC and related processes are within my scope of concern regarding editor retention, but they're not my expertise. I wish I could help more. Currently, when I'm not dealing with Cascadia Wikimedians budgets and events, my other item of great interest is VisualEditor, which I feel has come a long way. In Cascadia we intend to start to introduce new users to VisualEditor, using some presentation materials that I'm putting together, hopefully for eventual integration into a couple of videos.
Regarding broader editor engagement plans going forward, I would like to see those fleshed out by WMF, and I have that on my list of items to ask Rachel and/or Lila about if no one else does in the next few weeks.
Pine
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Fri, Apr 24, 2015 at 12:21 AM, Pete Forsyth peteforsyth@gmail.com wrote:
On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.pine@gmail.com wrote:
Philippe is on vacation, so I'm forwarding this to Rachel.
Thanks Pine. That's unfortunate, but maybe there is somebody (maybe Fabrice?) who can shed some light on the general thinking in the software development in this area. There have been several closely related things -- Article Creation Wizard, Draft: namespace, New Page Patrol software... -- and I see many references to an overall plan, but I've had difficulty finding a summary of that plan.
In the meantime, I've been trying to put the pieces together myself, and have gotten some good assistance from Nemo Bis and Aaron Halfaker -- see here:
https://meta.wikimedia.org/wiki/Research_talk:Wikipedia_article_creation#Cut...
At this point, in addition to clarification from Philippe about which part he was referring to, the main thing I'm hoping to accomplish is basically a timeline of milestones, more or less like this (I have somewhat made up the data below for the sake of illustrating the format):
- January 1, 2004: AFC process created. [[Wikilink to tool]] [diff or
mailing list for decision-making process]
- February 1, 2011: RfC on English Wikipedia calls for new procedure
[[wikilink to RfC]] [Bugzilla link for request]
- June 1, 2011: Articles for Creation wizard launched [[Wikilink]]
[discussion link] with these impacts on user experience: ** Impact 1 ** Impact 2 ** Impact 3... ...and so on.
Who at WMF would be best able to fill in the gaps in such a list? Or does the list already exist in a strategy document somewhere? I haven't been able to find it yet, but I'm still looking.
Pete [[User:Peteforsyth]] _______________________________________________ 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
As I cannot use it consistently myself without making errors, I'm not going to teach people the visual editor. I've done quite nicely teaching beginners to use the wiki syntax, by imitating what they see.
As I have spent most of my time for the last year and a half dealing with the gross deficiencies in AfC, I continue to feel that the best thing to do with it is to discontinue it altogether: it's an excellent example of technical solutions made without considering the inadequate number of skilled people to operate it, and the attraction it would have for the incompetent. (It also showed the lack of willingness of those devising it to make even the most obvious of changes (there is *still* no easy way to list multiple reasons for rejection without a manual over-ride) I cannot judge competence at the technical level except by the results.
Draft space was initiated by those like myself trying to find a replacement for it. We hoped it would replace, not just add on as it has done.
What I primarily want from the tech staff at WMF is to improve performance by fixing obsolete internal elements of the system. They finally seem to be doing that. What is equally needed but of less relevance to my own work is to do whatever depth of reprogramming is needed to accommodate mobile devices. They're doing that--how well I leave it to others to say.
On Fri, Apr 24, 2015 at 3:40 AM, Pine W wiki.pine@gmail.com wrote:
Hi Pete,
James A. might be able to answer that, or know which project manager to ping.
AFC and related processes are within my scope of concern regarding editor retention, but they're not my expertise. I wish I could help more. Currently, when I'm not dealing with Cascadia Wikimedians budgets and events, my other item of great interest is VisualEditor, which I feel has come a long way. In Cascadia we intend to start to introduce new users to VisualEditor, using some presentation materials that I'm putting together, hopefully for eventual integration into a couple of videos.
Regarding broader editor engagement plans going forward, I would like to see those fleshed out by WMF, and I have that on my list of items to ask Rachel and/or Lila about if no one else does in the next few weeks.
Pine
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Fri, Apr 24, 2015 at 12:21 AM, Pete Forsyth peteforsyth@gmail.com wrote:
On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.pine@gmail.com wrote:
Philippe is on vacation, so I'm forwarding this to Rachel.
Thanks Pine. That's unfortunate, but maybe there is somebody (maybe Fabrice?) who can shed some light on the general thinking in the software development in this area. There have been several closely related things
--
Article Creation Wizard, Draft: namespace, New Page Patrol software... -- and I see many references to an overall plan, but I've had difficulty finding a summary of that plan.
In the meantime, I've been trying to put the pieces together myself, and have gotten some good assistance from Nemo Bis and Aaron Halfaker -- see here:
https://meta.wikimedia.org/wiki/Research_talk:Wikipedia_article_creation#Cut...
At this point, in addition to clarification from Philippe about which
part
he was referring to, the main thing I'm hoping to accomplish is
basically a
timeline of milestones, more or less like this (I have somewhat made up
the
data below for the sake of illustrating the format):
- January 1, 2004: AFC process created. [[Wikilink to tool]] [diff or
mailing list for decision-making process]
- February 1, 2011: RfC on English Wikipedia calls for new procedure
[[wikilink to RfC]] [Bugzilla link for request]
- June 1, 2011: Articles for Creation wizard launched [[Wikilink]]
[discussion link] with these impacts on user experience: ** Impact 1 ** Impact 2 ** Impact 3... ...and so on.
Who at WMF would be best able to fill in the gaps in such a list? Or does the list already exist in a strategy document somewhere? I haven't been able to find it yet, but I'm still looking.
Pete [[User:Peteforsyth]] _______________________________________________ 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 25 April 2015 at 04:11, David Goodman dggenwp@gmail.com wrote:
As I cannot use it consistently myself without making errors, I'm not going to teach people the visual editor. I've done quite nicely teaching beginners to use the wiki syntax, by imitating what they see.
When did you last use it? I ask because I just started using it again after a long while not, and it's *ridiculously* better now than it was in its first six months. It's now at the sort of quality where I'd be enormously happy to put it in front of people, as it wasn't two years ago.
Also, it is the only sane way to edit tables. (The amazing thing about wikitext for tables is that it's actually worse than the plain HTML it replaced.) I expect your newbies will be less than pleased if they ever have to add or remove a table column and only later discover that the VE makes this a near-trivial task.
- d.
I put "model writing a new article with visual editor" on my to-do list. It may be a good idea to do a few test runs where we boot a hundred or so pages in each category in VisualEditor, and then see how many of each have errors. On Apr 25, 2015 1:51 PM, "David Gerard" dgerard@gmail.com wrote:
On 25 April 2015 at 04:11, David Goodman dggenwp@gmail.com wrote:
As I cannot use it consistently myself without making errors, I'm not
going
to teach people the visual editor. I've done quite nicely teaching beginners to use the wiki syntax, by imitating what they see.
When did you last use it? I ask because I just started using it again after a long while not, and it's *ridiculously* better now than it was in its first six months. It's now at the sort of quality where I'd be enormously happy to put it in front of people, as it wasn't two years ago.
Also, it is the only sane way to edit tables. (The amazing thing about wikitext for tables is that it's actually worse than the plain HTML it replaced.) I expect your newbies will be less than pleased if they ever have to add or remove a table column and only later discover that the VE makes this a near-trivial task.
- d.
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
James,
Pine suggested you might be able to fill in some of the gaps here. I am not tied to any given format, but what I'm looking for is the connective tissue between things like ACTRIAL, AFC and its increased use, Page Curation, the Draft: namespace, etc.
Reading through the associated pages on wiki, it appears (most specifically from a couple comments from Steven Walling) that there was a strategic framework at the WMF that tied this stuff together. But after spending 45 minutes or so browsing wiki discussions and feature pages, I didn't feel I was getting any closer to seeing what it was/is.
Can you help? Pete
On Fri, Apr 24, 2015 at 12:21 AM, Pete Forsyth peteforsyth@gmail.com wrote:
On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.pine@gmail.com wrote:
Philippe is on vacation, so I'm forwarding this to Rachel.
Thanks Pine. That's unfortunate, but maybe there is somebody (maybe Fabrice?) who can shed some light on the general thinking in the software development in this area. There have been several closely related things -- Article Creation Wizard, Draft: namespace, New Page Patrol software... -- and I see many references to an overall plan, but I've had difficulty finding a summary of that plan.
In the meantime, I've been trying to put the pieces together myself, and have gotten some good assistance from Nemo Bis and Aaron Halfaker -- see here: https://meta.wikimedia.org/wiki/Research_talk:Wikipedia_article_creation#Cut...
At this point, in addition to clarification from Philippe about which part he was referring to, the main thing I'm hoping to accomplish is basically a timeline of milestones, more or less like this (I have somewhat made up the data below for the sake of illustrating the format):
- January 1, 2004: AFC process created. [[Wikilink to tool]] [diff or
mailing list for decision-making process]
- February 1, 2011: RfC on English Wikipedia calls for new procedure
[[wikilink to RfC]] [Bugzilla link for request]
- June 1, 2011: Articles for Creation wizard launched [[Wikilink]]
[discussion link] with these impacts on user experience: ** Impact 1 ** Impact 2 ** Impact 3... ...and so on.
Who at WMF would be best able to fill in the gaps in such a list? Or does the list already exist in a strategy document somewhere? I haven't been able to find it yet, but I'm still looking.
Pete [[User:Peteforsyth]]
On Sep 1, 2014 5:10 PM, "Marc A. Pelletier" marc@uberbox.org wrote:
Warning, tl;dr rant below in which live my personal opinion.
Thank you for that. A heartfelt rant feels a lot better than being told my "call is important to you."
(snip)
The fundamental issue is that the WMF is attempting to provide some direction, and the communities do not want any (for various and divergent reasons).
I don't really have all that much of a problem with direction. I have a problem though with strong arming change, which is snap happened here.
(snip)
The process *does* need community engagement. That'd seriously increases the value of what (and how) the WMF does things, and likely reduce the number of bad ideas from the outset.
But the community engagement it needs is one that is done in good faith;
Yes, from both sides. The flow example cited in another email shows this well. There is a large contingent of "thank you for your concern. We won't do that because we believe x rather than y", effectively closing discussion. That's not a great atmosphere to share ideas in. Another frequent problem is saying in the early stages not to worry, it's only the early stages, and all that will be fixed, just come back in a few months, and you'll see how great it'll be, and when it isn't say that earlier feedback would have helped, but nobody showed interest in the early stages.
something which I have yet to see more than exceptions here and there. It also needs fewer reactionnary hotheads. Editing sucks. Reading is lacking. Most of the tooling is crap. That X editors have gotten used to it and have implemented piles of workarounds doesn't justify keeping the old shit around.
MV is a perfect example. 99% of the problems it objectively has (we ignore here matters of taste) derive from the difficulty of parsing the multitude overcomplicated templates living on File: pages to work around the fact that a wikitext page is complete and utter crap at storing metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds.
Yes! This must be said more often!
The *correct* solution is to fix the damn image pages, not to remove MV.
The *correct* solution is to make MV bail completely on pages it fails to parse, falling back to the known bad-but-sufficient behaviour, and maybe adding a hidden category unparsable by MV to the image, so that it can be addressed. If 10% of the effort spent on the long tail of template madness was spent on implementing "when in doubt, bail" much debate would have been unnecessary. Doing the right thing 90% of the time and nothing 10% of the time is preferable over doing the right thing 98 % of the time and the wrong thing 2%.
The same, by the way, goes for VE, which should have had "bail and give me what you have now as wikitext" from the onset, and Flow which needs a "bail and convert this thread to ye olde talkpage thread" (which I fear will be batted away as reactionary crank talk, and "by the time flow will be done unneeded anyway")
-- Martijn
How is it that the old saying goes? "'We've always done things this way' is the most dangerous statement in any language?"
-- Marc
On 1 September 2014 17:57, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
The same, by the way, goes for VE, which should have had "bail and give me what you have now as wikitext" from the onset, and Flow which needs a "bail and convert this thread to ye olde talkpage thread" (which I fear will be batted away as reactionary crank talk, and "by the time flow will be done unneeded anyway")
By the way:
Is Flow going to support the use case of cut'n'pasting a piece from the article page to the talk page, as a lump of wikitext or as a piece of rich text from VE?
'Cos if it doesn't, I predict that will be the sticking point with the people who actually communicate on talk pages.
- d.
On 09/01/2014 12:57 PM, Martijn Hoekstra wrote:
The *correct* solution is to make MV bail completely on pages it fails to parse, falling back to the known bad-but-sufficient behaviour, and maybe adding a hidden category unparsable by MV to the image, so that it can be addressed. If 10% of the effort spent on the long tail of template madness was spent on implementing "when in doubt, bail" much debate would have been unnecessary.
I don't think it's necessarily easy to even /detect/ that there is something important that couldn't be parsed right; but this makes sense to me indeed in principle.
-- Marc
Thank you very much, Marc, for this clear and sound statement. It seems to me that there are many discussions that are far away from the real points, like the multitude of information on our pages. I once counted how many links there are on the German main page of Wikimedia Commons, I stopped when I reached 170... By the way, I enjoyed your talk at Wikimania, and your enthousiasm about many tools - actually, tools that often help to overcome the downsides of our wiki pages. Kind regards Ziko
2014-09-01 17:10 GMT+02:00 Marc A. Pelletier marc@uberbox.org:
Warning, tl;dr rant below in which live my personal opinion.
On 09/01/2014 08:00 AM, Craig Franklin wrote:
fter the catastrophic aborted launch of the Visual Editor, complete with numerous bugs that should have been picked up in even a cursory unit testing scheme or regression testing scheme prior to being deployed to a productive environment, there's not a good deal of faith left.
That /was/ a bad botch; and (IMO) the reason why that happened is that someone set a hard deploy date that should never have been set in stone and then held to it even though VE was clearly not ready. (It is *now* at a point with rollout would have been plausible).
Clearly nobody at WMF Engineering is going to do *that* again.
But I also don't think that was causative in any way; the tension between WMF holding the reins to the servers and (part of) the communities was the same years before that. ACCTRIAL anyone?
The fundamental issue is that the WMF is attempting to provide some direction, and the communities do not want any (for various and divergent reasons).
I side with the WMF in this; not because they sign my paycheck (I'm in Ops - I have zero to do with dev work) but because I've been a Wikipedian for >10 years and I *see* that the communities have no capacity for change - or that what little change manages to gather micro-consensus is local and often shortsighted. The projects are directionless, and it shows in the increasing stagnation and calcification.
Are all the attempts by the WMF at providing direction successes? Not even close. Some of the things they tried ranged from merely misguided to downright daft (also IMO, obviously).
The process *does* need community engagement. That'd seriously increases the value of what (and how) the WMF does things, and likely reduce the number of bad ideas from the outset.
But the community engagement it needs is one that is done in good faith; something which I have yet to see more than exceptions here and there. It also needs fewer reactionnary hotheads. Editing sucks. Reading is lacking. Most of the tooling is crap. That X editors have gotten used to it and have implemented piles of workarounds doesn't justify keeping the old shit around.
MV is a perfect example. 99% of the problems it objectively has (we ignore here matters of taste) derive from the difficulty of parsing the multitude overcomplicated templates living on File: pages to work around the fact that a wikitext page is complete and utter crap at storing metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. The *correct* solution is to fix the damn image pages, not to remove MV.
How is it that the old saying goes? "'We've always done things this way' is the most dangerous statement in any language?"
-- Marc
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,
Thanks for your message. I think it is honest and useful.
2014-09-01 20:40 GMT+05:30 Marc A. Pelletier marc@uberbox.org: ...
MV is a perfect example. 99% of the problems it objectively has (we ignore here matters of taste) derive from the difficulty of parsing the multitude overcomplicated templates living on File: pages to work around the fact that a wikitext page is complete and utter crap at storing metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. The *correct* solution is to fix the damn image pages, not to remove MV.
OK, I could buy that. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth?
How is it that the old saying goes? "'We've always done things this way' is the most dangerous statement in any language?"
-- Marc
Regards,
Yann
On 09/02/2014 02:52 AM, Yann Forget wrote:
OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth?
In the best of worlds, that would have been ideal.
Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single "<references/>" onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario.
Perhaps the problem is more fundamental than this, and we're only seeing symptoms. I don't know.
But I /do/ know that waiting until every edge case is handled before deploying (attempted) improvements to the site is doomed to failure. If only because most of the edge case won't even be /findable/ until the software is in place so that it can't work even in principle.
IMO, in practice, "get it working for the general case and most of the obvious edge cases" is a reasonable standard; and I'm pretty sure that MV qualified under that metric (and VE didn't).
I suppose much of my frustration over the MV keruffle is borne out of a reaction I see much too often for my taste: editors yelling "OMG, look, image X isn't properly attributed/licensed/etc in MV! Burn it with fire!!!" rather than figuring out why X's image page isn't properly parsed and /fixing/ it (and possibly an underlying template that could fix dozen/hundred others in one fell swoop).I'm pretty sure that if half as much effort had been spent fixing issues as was attempting to kill MV, its fail rate would already be at "statistical anomaly" levels.
.. but my inner cynic is also pretty sure that many of the loudest voices wanting to get rid of MV ostensibly because of its failings don't actually /want/ those failings to be fixed because being able to say "It's broken" rather than "I don't like it" sounds much more rational.
-- Marc
I don't think people yell "MediaViewer is broken" as much as they yell "MediaViewer broke my workflow!". The problem is that no one cares about some editor's personal workflow, so maybe we should be documenting use cases that could be used for new & old editors and developers alike
On Tue, Sep 2, 2014 at 7:46 AM, Marc A. Pelletier marc@uberbox.org wrote:
On 09/02/2014 02:52 AM, Yann Forget wrote:
OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth?
In the best of worlds, that would have been ideal.
Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single "<references/>" onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario.
Perhaps the problem is more fundamental than this, and we're only seeing symptoms. I don't know.
But I /do/ know that waiting until every edge case is handled before deploying (attempted) improvements to the site is doomed to failure. If only because most of the edge case won't even be /findable/ until the software is in place so that it can't work even in principle.
IMO, in practice, "get it working for the general case and most of the obvious edge cases" is a reasonable standard; and I'm pretty sure that MV qualified under that metric (and VE didn't).
I suppose much of my frustration over the MV keruffle is borne out of a reaction I see much too often for my taste: editors yelling "OMG, look, image X isn't properly attributed/licensed/etc in MV! Burn it with fire!!!" rather than figuring out why X's image page isn't properly parsed and /fixing/ it (and possibly an underlying template that could fix dozen/hundred others in one fell swoop).I'm pretty sure that if half as much effort had been spent fixing issues as was attempting to kill MV, its fail rate would already be at "statistical anomaly" levels.
.. but my inner cynic is also pretty sure that many of the loudest voices wanting to get rid of MV ostensibly because of its failings don't actually /want/ those failings to be fixed because being able to say "It's broken" rather than "I don't like it" sounds much more rational.
-- Marc
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 generally agree with your analysis Marc, notwithstanding that there is blame to share on all sides - not just users who point to broken edge cases. The (quite predictable) behaviour you mention is why I was quite fond of the way the "usability initiative" from several years ago (the team that built the Vector skin) operated.
They made it very easy to opt-in AND out of the beta version of their work. They also made it very clear that when the proportion of people who stayed "in" reached a certain level (If I recall correctly it was 80% and certainly not 95%+), that would signal that the software had reached a certain level of acceptance, and that a sufficient number of edge-cases had been addressed. Until that point they would focus on working with the people who has tried the beta but had turned it OFF, to identify their personal edge cases - in the hope this would fix other people's problems. Much like you described.
The key here in my opinion is: - clear communication about what state constitutes "success" (e.g. "When 80% of people who have opted in have STAYED opted-in") - clear communication about the progress towards that state (e.g. Showing the "success" factor in the little statistics on the "beta features" tab, and showing how close we are to that.) - only moving to the next stage when that state has been reached, (not a fixed schedule but "it is ready when it is ready, not before") - making it easy to try, and withdraw from, new things, always starting with opt-in before making it opt-out.
Since the "usability initiative" there has now been introduced the "beta" preferences function for editors to test new software and provide feedback. I would like to see this used more consistently and with more clarity about what stage of "beta" the individual elements within that system are at. Currently all I know is that there is a list of items and that there is an absolute number of users for each item (e.g. "1,234 people are using this.") Would it be difficult to make it show what proportion of people who have tried any given beta feature are STILL using it? That would give an indicator of popularity/acceptance at least.
-Liam / Wittylama.
On Tuesday, 2 September 2014, Marc A. Pelletier marc@uberbox.org wrote:
On 09/02/2014 02:52 AM, Yann Forget wrote:
OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth?
In the best of worlds, that would have been ideal.
Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single "<references/>" onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario.
Perhaps the problem is more fundamental than this, and we're only seeing symptoms. I don't know.
But I /do/ know that waiting until every edge case is handled before deploying (attempted) improvements to the site is doomed to failure. If only because most of the edge case won't even be /findable/ until the software is in place so that it can't work even in principle.
IMO, in practice, "get it working for the general case and most of the obvious edge cases" is a reasonable standard; and I'm pretty sure that MV qualified under that metric (and VE didn't).
I suppose much of my frustration over the MV keruffle is borne out of a reaction I see much too often for my taste: editors yelling "OMG, look, image X isn't properly attributed/licensed/etc in MV! Burn it with fire!!!" rather than figuring out why X's image page isn't properly parsed and /fixing/ it (and possibly an underlying template that could fix dozen/hundred others in one fell swoop).I'm pretty sure that if half as much effort had been spent fixing issues as was attempting to kill MV, its fail rate would already be at "statistical anomaly" levels.
.. but my inner cynic is also pretty sure that many of the loudest voices wanting to get rid of MV ostensibly because of its failings don't actually /want/ those failings to be fixed because being able to say "It's broken" rather than "I don't like it" sounds much more rational.
-- Marc
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 javascript:; ?subject=unsubscribe>
On 09/02/2014 10:35 AM, Liam Wyatt wrote:
The key here in my opinion is:
- clear communication about what state constitutes "success" (e.g. "When
80% of people who have opted in have STAYED opted-in")
- clear communication about the progress towards that state (e.g. Showing
the "success" factor in the little statistics on the "beta features" tab, and showing how close we are to that.)
- only moving to the next stage when that state has been reached, (not a
fixed schedule but "it is ready when it is ready, not before")
- making it easy to try, and withdraw from, new things, always starting
with opt-in before making it opt-out.
This sounds sane indeed. +1 from me, at the very least. Note how VE did pretty much the opposite of that, and that was a disaster (the rollout, not VE itself).
-- Marc
On 02/09/14 11:46, Marc A. Pelletier wrote:
On 09/02/2014 02:52 AM, Yann Forget wrote:
OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth?
In the best of worlds, that would have been ideal.
Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single "<references/>" onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario.
I have. It's a lot of work to set up and keep on track, and can take a goodly long while to get going at all, but when it succeeds, it's totally AWESOME.
Wasn't on Wikimedia, but should be totally doable here, too, provided the time, energy, and utter insanity required. Principles are the same.
-I
On Wed, Sep 3, 2014 at 12:58 PM, Isarra Yos zhorishna@gmail.com wrote:
On 02/09/14 11:46, Marc A. Pelletier wrote:
On 09/02/2014 02:52 AM, Yann Forget wrote:
OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth?
In the best of worlds, that would have been ideal.
Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single "<references/>" onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario.
I have. It's a lot of work to set up and keep on track, and can take a goodly long while to get going at all, but when it succeeds, it's totally AWESOME.
Wasn't on Wikimedia, but should be totally doable here, too, provided the time, energy, and utter insanity required. Principles are the same.
+1
The Wikimedia Foundation operates in a world in which incredible efforts at collaboration, consensus-building, and creating standards in complex environments happens *every day* -- but, that doesn't fit in too well with the preferred narrative of "our community is impossible to wrangle." Maybe that is why the lessons get ignored?
Pete [[User:Peteforsyth]]
The Technology Committee would be well positioned to help create standards across projects. Also, if there is a need to have a common set of features across projects, I would prefer to have the Technology Committee make those decisions. By doing so, the principles of democracy and consensus would apply, and the benefits of features commonality could still be achieved.
Marc, thank you for speaking candidly.
Pine
On Wed, Sep 3, 2014 at 1:01 PM, Pete Forsyth peteforsyth@gmail.com wrote:
On Wed, Sep 3, 2014 at 12:58 PM, Isarra Yos zhorishna@gmail.com wrote:
On 02/09/14 11:46, Marc A. Pelletier wrote:
On 09/02/2014 02:52 AM, Yann Forget wrote:
OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth?
In the best of worlds, that would have been ideal.
Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single "<references/>" onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario.
I have. It's a lot of work to set up and keep on track, and can take a goodly long while to get going at all, but when it succeeds, it's totally AWESOME.
Wasn't on Wikimedia, but should be totally doable here, too, provided the time, energy, and utter insanity required. Principles are the same.
+1
The Wikimedia Foundation operates in a world in which incredible efforts at collaboration, consensus-building, and creating standards in complex environments happens *every day* -- but, that doesn't fit in too well with the preferred narrative of "our community is impossible to wrangle." Maybe that is why the lessons get ignored?
Pete [[User:Peteforsyth]] _______________________________________________ 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, Maybe... but it assumes that we have plenty of time and work sequently. Both are not the case and as it is, the framework is broken.to the extend that people refuse to use it. So yes, ideally you want to fix many issues nicely and in a collaborative manner. At the same time our readers are disappearing from our old platform and new editors are not happening on the old platform.
The question is very much to what extend we can suffer all the baggage and backlog from the past. The question is very much what to do when we do not have that 80% on a subject that stops other developments. Thanks, GerardM
On 3 September 2014 21:58, Isarra Yos zhorishna@gmail.com wrote:
On 02/09/14 11:46, Marc A. Pelletier wrote:
On 09/02/2014 02:52 AM, Yann Forget wrote:
OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth?
In the best of worlds, that would have been ideal.
Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single "<references/>" onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario.
I have. It's a lot of work to set up and keep on track, and can take a goodly long while to get going at all, but when it succeeds, it's totally AWESOME.
Wasn't on Wikimedia, but should be totally doable here, too, provided the time, energy, and utter insanity required. Principles are the same.
-I
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, Maybe... but it assumes that we have plenty of time and work sequently. Both are not the case and as it is, the framework is broken.to the extend that people refuse to use it. So yes, ideally you want to fix many issues nicely and in a collaborative manner. At the same time our readers are disappearing from our old platform and new editors are not happening on the old platform.
Open source has a lot of benefits. Delivering quality software '''on a schedule''' is not one of them. But it can be done. We did it with Zend Framework with quarterly major releases. We also turned community sentiment around after the negative reaction to 1.0, which was released right before I joined Zend.
I'd say that the most impactful thing we did to right the ship was hearing people out wherever they chose to discuss ZF. We monitored all channels of communication and responded to frustrations as quickly as possible. Most of our comments boiled down to:
"You're right. We have a problem here. Will you help us fix it?"
In other words, we made sure we walked the walk so that we could invite others to walk with us. And the constructive critics figured out that walking is more fun/satisfying than all the talking. Of course, that meant we walked away from some critics who weren't interested in being constructive. We never looked back.
I believe this community can also turn all this dysfunction and stress in to something positive. So, let's start walking; here's a proposal/challenge for those who think Media Viewer isn't worthy:
Take all that time you're investing in petitioning the community and use it to build something better than Media Viewer. A lot of you have already identified pain points in MV and some solutions have also been put forward; so, if you are not planning to get involved in the project that the WMF has set up for whatever reasons, join us in building what Media Viewer should be without the complications of dealing with the WMF. If it turns out to be a better solution than Media Viewer, then I suggest we create a petition to replace MV with the community's solution. That's the kind of positive, action-oriented petition I can sign.
I'll even kick it off. We can start listing the requirements for the Worthy Media Viewer on this page: https://meta.wikimedia.org/wiki/WorthyMV.
So, who's ready to walk?
,Wil
"No employee should be made to receive that sort of harassment in the course of their job, no matter how much you disagree with them."
How did it come to be part of Erik's job to create superprotect and attempt to force the community to accept it? As the WMF is defined in its mission statement, its purpose is to "empower and enable" the community to create the projects. Somehow disabling the community came to be seen as legitimate. Erik was, we suspect, highly involved in that, but really this is between Erik and his management.
The wiki communities often harass unpopular messengers. This isn't just about Erik, it's about how wikis function, and unless the WMF manages to facilitate clearer and more efficient and more reliable community process, it's very likely to stay that way, because these kinds of community characteristics are self-reinforcing, since anything else is driven away. Solutions are prohibited, crushed immediately.
The real issue in this affair, as many have noted, was not MediaViewer, it was about power and control, which are survival issues, instinctive for human beings. Anyone who was surprised by the intensity of the response doesn't know human beings. Not surprising, I suppose, for software people. But shocking for the WMF as a whole, so I'm hoping that there is some real soul-searching in the WMF offices. This was *entirely predictable.*
Abd ul-Rahman Lomax (413) 584-3151 business (413) 695-7114 cell I'm so excited I can't wait for Now.
From: Craig Franklin cfranklin@halonetwork.net To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Sent: Monday, September 1, 2014 8:00 AM Subject: Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments
I think you've hit the nail on the head here. It's not about MediaViewer at all, it's about two things:
#1: The frustration of some volunteers that they feel their views are not being adequately considered in major deployments of new software. #2: A lack of confidence and faith in the WMF Engineering team to deliver quality software.
The second is the more dangerous one at this point. After the catastrophic aborted launch of the Visual Editor, complete with numerous bugs that should have been picked up in even a cursory unit testing scheme or regression testing scheme prior to being deployed to a productive environment, there's not a good deal of faith left. The technical problems with MediaViewer were not as serious, but since a significant portion of the power user base was expecting a failure, they jumped on the flaws that it did have, and here we are. To be honest, if Erik were to turn water into wine at this point, people would still complain, and loudly, that he had provided them with red when they wanted white.
I'm not sure that the solutions that have been offered; a new deployment process, or a tech council, are going to be sufficient to correct the real problem, which at this point is largely one of perception. Similarly, I don't think that the WMF adopting a complete hands-off approach as some seem to be demanding is going to lead to anything other than stagnation as individual communities squabble indecisively over what changes should be made. I do know that if it's not fixed, that pretty much every major deployment of new features is going to follow this same pattern, which is obviously highly undesirable.
What I'd suggest is that we leave the "emotional hostility" at the door and try to be reasonable. Neither side is going to get exactly what they want, and that is to be expected. To be honest, some of the invective that has been directed at Foundation staff has been completely over the top; phrases like "Taliban diplomacy" or honest-to-god comparisons to the Nazis don't move us towards a solution or make one seem like someone that can be intelligently reasoned with, they only harden feelings on both sides and make a suitable arrangement being found less likely. No employee should be made to receive that sort of harassment in the course of their job, no matter how much you disagree with them.
Cheers, Craig Franklin
Yes, it is emotions that speak, though emotions are often concealed beneath "arguments." Basic human psychology.
Any attempt to ascribe this affair to "sour grapes" from a disgruntled software developer is looking at a bush in the forest and not the massive collection of trees. No, it's about basic survival issues, it's called "avoiding domination," a nearly universal trait that appears to be instinctive.
There are *also* "rational" issues, but it was not reason that led the WMF to, in a rush, create and impose superprotect, and it was not reason that led to all the extreme comments from the community. We don't expect the community to be reasonable, as to every comment, but we do have higher expectations of people employed to serve us.
It is likely, to me, that the root problem here was a new ED, who believed that her mission was to create a better experience for *readers*, and, my guess, she was encouraged to believe that by some of the Staff. And, of course, as a skilled manager from software companies, she would support and rely on the Staff for advice. However, there is a higher master, always, the customers. Those who actually pay the bills.
Who are they? Well, we could talk about the donors, but there is a much larger contributor to the WMF, and it contributes labor, not money. That labor makes the projects possible. Some thought that the superprotect decision was a deliberate attempt to shove the community away, to move toward bot maintenance, to kick the experienced users out the door. I don't think so. I think it was simply inept, though an inept decision that might be expected from an *experienced software company manager.*
Who was not informed that the community is the actual customer, not the readers.
Who, I assume, can learn.
Abd ul-Rahman Lomax (413) 584-3151 business (413) 695-7114 cell I'm so excited I can't wait for Now.
From: Gerard Meijssen gerard.meijssen@gmail.com To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Sent: Monday, September 1, 2014 2:31 AM Subject: Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments
Hoi, The argument is not at all about the MediaViewer. It is only the latest flash point. Consequently the notion of how hard it is to set a default on or off is not relevant really.
When you read the Wikipedia Signpost you read about one of the major German players and it is found necessary to mention that his "tools" environment was ended and it became WMF labs. For me it gives the impression of sour grapes and a sense of failure because volunteers do not decide the agenda and feel angry/frustrated about that.
Consequently my conclusion that it is not about the MediaViewer at all. The next thing that comes along will be the next flash point. This is because it is emotions that speak and not arguments. Thanks, GerardM
On 1 September 2014 08:11, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Aug 31, 2014 11:46 PM, "Pine W" wiki.pine@gmail.com wrote:
Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for
the
projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead
of
feuding, and I'm getting MediaViewer issue fatigue.
WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make
global
decisions on a consensus basis.
Pine
I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different projects, and frankly, I'm not buying it, unless the setting is intended to be removed completely.
Could someone explain to me how having a different default state for the setting has much, or any, impact?
- Martijn
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@lists.wikimedia.org