Re: [Wikimedia-l] Community RfCs about MediaViewer
On Fri, Jul 11, 2014 at 9:40 AM, Erik Moeller e...@wikimedia.org wrote: On Thu, Jul 10, 2014 at 4:12 PM, MZMcBride z...@mzmcbride.com wrote: Many new features (e.g., the improved search backend) are deployed fairly regularly without fanfare or objection. Indeed, change-aversion tends to correlate pretty strongly with impact on existing workflows [1] and noticeable changes to user experience and behavior. This is pretty clearly laid out by a Google UX researcher here: https://www.gv.com/lib/change-aversion-why-users-hate-what-you-launched-and-what-to-do-about-it Media Viewer is actually a perfect example of this -- most of the functionality people expect (get to the File: page, see a summary, see categories, get the full-size version, get multiple resolutions, see attribution information, etc.) is there; ... Or .. sometimes the licensing and attribution information isnt correct, sometimes you get resolutions which are silly (especially svgs at launch, but also slideshows on a file page include a very large license logo), it takes extra clicks to get to the full-size version, only some of the categories are shown including otherwise 'hidden' categories, and sometimes the summary isnt shown. These are a combination of design flaws and blatant bugs which were known before launch. Has the WMF done a quick estimate on the amount of time before these basic functions of media viewer are working correctly? Has the WMF allocated developers to ensure these basic functions of media viewer work correct? I would be much happier to support it remaining opt out if WMF could give an estimate on when this will be completed, rather than reading WMF directors say 'most of the functionality people expect ... is there'. It's not, except in the 'proof of concept' mode. Its a long way from being ready to leave beta, much like Visual Editor was. -- John Vandenberg ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
While I'm not necessarily disagreeing with you, Todd, there were 14,681 users on English Wikipedia alone who had enabled MediaViewer using the Beta Features preference before it became the default. That's a huge number of people who were all using it every time they clicked on an image in the weeks and months beforehand, and every one of them had to make a conscious decision to turn it on. The 64 users who want it disabled as default pale in comparison to the number of people who were actively using it beforehand. I've asked for some better statistical information because I don't think the Limn graphs that have been referred to in the discussion of the RFC are really accurate; it's my understanding that about 1600 registered accounts have opted out of MV in total (this should be a linear graph of the cumulative total, not a daily number of people who opted out graph which is what we seem to see now). As well, somewhere in the neighbourhood of 500 logged out users a day are disabling it - this needs to be a daily number, not a cumulative one, because logged-out disabling is linked to the individual browser session; those who aren't logged in don't have the chance to set preferences. There are between 4 and 5 *million* clicks on image thumbnails every day on enwiki, with only around 500 of those viewing the images disabling the MediaViewer (excluding logged-in users who have turned it off in their preferences). I suspect that at the end of the day, MediaViewer is going to be more like the switch to Vector skin: there will be plenty of people who choose to disable for reasons that work for them, but the overwhelming majority of users will be entirely fine with the default. It's having nowhere near the impact that VisualEditor had when first enabled as default; in the first 48 hours there were hundreds of how do you turn this off queries and complaints about functionality, not to mention pretty much automatic reverting of edits done by IPs because there were so many VE-related problems associated with them. We're not at that level at all here. I agree with John Vandenberg's comments that a clear roadmap and prioritized list of next steps is probably required for MediaViewer. Risker/Anne On 11 July 2014 00:56, Todd Allen toddmal...@gmail.com wrote: If you don't want to do small opt-in trials, release software in a fully production-ready and usable state. What's getting released here is barely ready for beta. It's buggy, it's full of unexpected UX issues, it's not ready to go live on one of the top 10 websites in the world. It's got to be in really good shape to get there. Until software is actually ready for widescale use, small and very limited beta tests are exactly the way to go, followed by maybe slightly larger UAT pools. Yeah, that takes longer and requires actual work to find willing testers. Quit taking shortcuts through your volunteers. On Thu, Jul 10, 2014 at 10:40 PM, Sue Gardner sgard...@wikimedia.org wrote: Hey guys, I use MediaViewer, I like it, and I am happy to trust the WMF product team to build stuff. I didn't know about the RFC, but even if I had I would've been unlikely to have participated, because I don't think small opt-in discussions are the best way to do product development -- certainly not at the scale of Wikipedia. I think we should aim on this list to be modest rather than overreaching in terms of what we claim to know, and who we imply we're representing. It's probably best to be clear --both in the mails we write and in our own heads privately-- that what's happening here is a handful of people talking on a mailing list. We can represent our own opinions, and like David Gerard we can talk anecdotally about what our friends tell us. But I don't like it when people here seem to claim to speak on behalf of editors, or users, or readers, or the community. It strikes me as hubristic. Thanks, Sue On 10 Jul 2014 16:13, MZMcBride z...@mzmcbride.com wrote: Erik Moeller wrote: In this case, we will keep the feature enabled by default (it's easy to turn off, both for readers and editors), but we'll continue to improve it based on community feedback (as has already happened in the last few weeks). Thanks for the reply. :-) If your feature development model seemingly requires forcing features on users, it's probably safe to say that it's broken. If you're building cool new features, they will ideally be uncontroversial and users will actively want to enable them and eventually have them enabled by default. Many new features (e.g., the improved search backend) are deployed fairly regularly without fanfare or objection. But I see a common thread among unsuccessful deployments of features such as ArticleFeedbackv5, VisualEditor, and MediaViewer. Some of it is the people involved, of course, but the larger pattern is a fault in the process, I think. I
Re: [Wikimedia-l] Community RfCs about MediaViewer
Risker, I'm actually not going to disagree with you in principle. I ultimately see Media Viewer being used by a good number of users, and said as much from the start. But I also warned that a bulldozer approach was going to cause massive blowback, especially after the previous debacles (VE and ACTRIAL come to mind for me). And well, here we are, with another repeat of the VE situation. That greatly eroded trust in WMF, especially its dev teams and PMs, and that's nowhere even close to rebuilt yet. Now that lack of trust is being confirmed and entrenched. WMF needs to step very lightly with deployments that will affect editors, and treat the volunteer community as an ally rather than adversary. If that doesn't happen, these showdowns will keep happening. Part of that is pure arrogance. A significant part of the reason the Vector switch worked is because there was an easy, clearly accessible, one-click option that said Do not want, disable this!. If that'd been the case here, I would have clicked that and forgotten about it. Instead, I had to dig for an hour to find how to disable the thing, after being surprised by a totally unexpected change. But now we hear things like We made Vector opt-out too easy! Media Viewer probably does have its place, once it is fully functional and free of major bugs. I might even turn it on at that point. But shoving it down people's throats will only serve to further place the WMF's flagship project and the WMF at odds. That is not, I can't imagine, a desirable situation by anyone's estimation. WMF needs a far better deployment strategy than YOU ARE GETTING IT, LIKE IT OR NOT, AND THAT IS FINAL! If the WMF's strategy for when the core community and dev team disagree is We're right, you're wrong, pipe down, these situations will increase in frequency and intensity. I want to stop that before it reaches a real boiling point, and it could've this time if someone had actually gotten desysopped. On Fri, Jul 11, 2014 at 12:21 AM, Risker risker...@gmail.com wrote: While I'm not necessarily disagreeing with you, Todd, there were 14,681 users on English Wikipedia alone who had enabled MediaViewer using the Beta Features preference before it became the default. That's a huge number of people who were all using it every time they clicked on an image in the weeks and months beforehand, and every one of them had to make a conscious decision to turn it on. The 64 users who want it disabled as default pale in comparison to the number of people who were actively using it beforehand. I've asked for some better statistical information because I don't think the Limn graphs that have been referred to in the discussion of the RFC are really accurate; it's my understanding that about 1600 registered accounts have opted out of MV in total (this should be a linear graph of the cumulative total, not a daily number of people who opted out graph which is what we seem to see now). As well, somewhere in the neighbourhood of 500 logged out users a day are disabling it - this needs to be a daily number, not a cumulative one, because logged-out disabling is linked to the individual browser session; those who aren't logged in don't have the chance to set preferences. There are between 4 and 5 *million* clicks on image thumbnails every day on enwiki, with only around 500 of those viewing the images disabling the MediaViewer (excluding logged-in users who have turned it off in their preferences). I suspect that at the end of the day, MediaViewer is going to be more like the switch to Vector skin: there will be plenty of people who choose to disable for reasons that work for them, but the overwhelming majority of users will be entirely fine with the default. It's having nowhere near the impact that VisualEditor had when first enabled as default; in the first 48 hours there were hundreds of how do you turn this off queries and complaints about functionality, not to mention pretty much automatic reverting of edits done by IPs because there were so many VE-related problems associated with them. We're not at that level at all here. I agree with John Vandenberg's comments that a clear roadmap and prioritized list of next steps is probably required for MediaViewer. Risker/Anne On 11 July 2014 00:56, Todd Allen toddmal...@gmail.com wrote: If you don't want to do small opt-in trials, release software in a fully production-ready and usable state. What's getting released here is barely ready for beta. It's buggy, it's full of unexpected UX issues, it's not ready to go live on one of the top 10 websites in the world. It's got to be in really good shape to get there. Until software is actually ready for widescale use, small and very limited beta tests are exactly the way to go, followed by maybe slightly larger UAT pools. Yeah, that takes longer and requires actual work to find willing testers. Quit taking shortcuts through your
Re: [Wikimedia-l] Community RfCs about MediaViewer
There's a easy, clearly accessible, one-click option for disabling MediaViewer, Todd. Scroll to the bottom of the screen. Click disable. Done - it automatically changes your preference. Risker/Anne On 11 July 2014 02:44, Todd Allen toddmal...@gmail.com wrote: Risker, I'm actually not going to disagree with you in principle. I ultimately see Media Viewer being used by a good number of users, and said as much from the start. But I also warned that a bulldozer approach was going to cause massive blowback, especially after the previous debacles (VE and ACTRIAL come to mind for me). And well, here we are, with another repeat of the VE situation. That greatly eroded trust in WMF, especially its dev teams and PMs, and that's nowhere even close to rebuilt yet. Now that lack of trust is being confirmed and entrenched. WMF needs to step very lightly with deployments that will affect editors, and treat the volunteer community as an ally rather than adversary. If that doesn't happen, these showdowns will keep happening. Part of that is pure arrogance. A significant part of the reason the Vector switch worked is because there was an easy, clearly accessible, one-click option that said Do not want, disable this!. If that'd been the case here, I would have clicked that and forgotten about it. Instead, I had to dig for an hour to find how to disable the thing, after being surprised by a totally unexpected change. But now we hear things like We made Vector opt-out too easy! Media Viewer probably does have its place, once it is fully functional and free of major bugs. I might even turn it on at that point. But shoving it down people's throats will only serve to further place the WMF's flagship project and the WMF at odds. That is not, I can't imagine, a desirable situation by anyone's estimation. WMF needs a far better deployment strategy than YOU ARE GETTING IT, LIKE IT OR NOT, AND THAT IS FINAL! If the WMF's strategy for when the core community and dev team disagree is We're right, you're wrong, pipe down, these situations will increase in frequency and intensity. I want to stop that before it reaches a real boiling point, and it could've this time if someone had actually gotten desysopped. On Fri, Jul 11, 2014 at 12:21 AM, Risker risker...@gmail.com wrote: While I'm not necessarily disagreeing with you, Todd, there were 14,681 users on English Wikipedia alone who had enabled MediaViewer using the Beta Features preference before it became the default. That's a huge number of people who were all using it every time they clicked on an image in the weeks and months beforehand, and every one of them had to make a conscious decision to turn it on. The 64 users who want it disabled as default pale in comparison to the number of people who were actively using it beforehand. I've asked for some better statistical information because I don't think the Limn graphs that have been referred to in the discussion of the RFC are really accurate; it's my understanding that about 1600 registered accounts have opted out of MV in total (this should be a linear graph of the cumulative total, not a daily number of people who opted out graph which is what we seem to see now). As well, somewhere in the neighbourhood of 500 logged out users a day are disabling it - this needs to be a daily number, not a cumulative one, because logged-out disabling is linked to the individual browser session; those who aren't logged in don't have the chance to set preferences. There are between 4 and 5 *million* clicks on image thumbnails every day on enwiki, with only around 500 of those viewing the images disabling the MediaViewer (excluding logged-in users who have turned it off in their preferences). I suspect that at the end of the day, MediaViewer is going to be more like the switch to Vector skin: there will be plenty of people who choose to disable for reasons that work for them, but the overwhelming majority of users will be entirely fine with the default. It's having nowhere near the impact that VisualEditor had when first enabled as default; in the first 48 hours there were hundreds of how do you turn this off queries and complaints about functionality, not to mention pretty much automatic reverting of edits done by IPs because there were so many VE-related problems associated with them. We're not at that level at all here. I agree with John Vandenberg's comments that a clear roadmap and prioritized list of next steps is probably required for MediaViewer. Risker/Anne On 11 July 2014 00:56, Todd Allen toddmal...@gmail.com wrote: If you don't want to do small opt-in trials, release software in a fully production-ready and usable state. What's getting released here is barely ready for beta. It's buggy, it's full of unexpected UX issues, it's not ready to go live on one of the top
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jay...@gmail.com wrote: Or .. sometimes the licensing and attribution information isnt correct In the common case, Media Viewer provides more prominent and appropriate attribution and license information than the File: page. The author name, license, license URL, and source URL are all immediately accessible below the image, whereas on the File: page there are sometimes screenfuls of metadata between the image and this crucial information. This is actually a pretty remarkable accomplishment given that this information comes from a huge number of different templates that vary across wikis. Media Viewer makes use of standardized CSS classes to extract metadata, and the team has actively worked with the community to broaden their use: http://lists.wikimedia.org/pipermail/multimedia/2014-March/000135.html Ultimately we'll want to use proper structured data for this, but these changes lay the groundwork, and there's already an API (used by Media Viewer but open to anyone) that exposes this information. Where no license is detected, Media Viewer still falls back to a View license link. The more problematic cases are where actual errors occur and important information is not extracted, and there will certainly inevitably be some cases where this happens, but this can only be worked on over time. The expectation that an unbounded problem like this is completely solved prior to deployment of a feature is unreasonable -- it's similar to TemplateData, in that the positive feedback loop into Media Viewer should actually help encourage more and consistent use of machine-readable data. sometimes you get resolutions which are silly (especially svgs at launch, but also slideshows on a file page include a very large license logo) Can you give a specific, current example? it takes extra clicks to get to the full-size version, It takes exactly one click using the View original file button. 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikimedia Announcements] 2014-15 Annual Plan of the Wikimedia Foundation
Pete, I am looking more at process than outcomes. Asaf, perhaps I was unclear in my statement, so I will try again. 1. I do not expect WMF and grantmaking committees to agree all of the time. What I hope for is that WMF will not override a committee vote if a committee develops consensus against a proposal. Given GAC's low participation numbers it seems unlikely that they are forming consensus, as you say, but in the examples I gave WMF has approved grants that the majority (of one!) voted against. I think this is a risky practice that establishing grants committees is partly designed to mitigate. I am glad to hear that WMF has never done an override of a consensus vote of GAC and I hope it stays that way. 2. I would say that the system is not working if there is too low of a level of participation by Committee members to form consensus on proposals, and one thing there does seem to be consensus about is that the level of participation is too low. 3. Thank you for the links. Pine On Thu, Jul 10, 2014 at 12:32 PM, Pete Forsyth petefors...@gmail.com wrote: As someone who has engaged with several different grants, in different roles, through this program (as a grantee, as an advisor, as an interested volunteer), I would like to wholeheartedly endorse everything Asaf just said. Disagreement is a given when money and broad goals involved; if the grant program were run in such a way that there *wasn't* any visible disagreement, that would be a problem. I think those working on this program have, over the years, done an admirable job of working through the inevitable disagreements. Pete [[User:Peteforsyth]] On Thu, Jul 10, 2014 at 12:11 PM, Asaf Bartov abar...@wikimedia.org wrote: On Wed, Jul 9, 2014 at 10:15 PM, Pine W wiki.p...@gmail.com wrote: Thank you for the update, Alex. I find it problematic that WMF would override a community grantmaking committee that WMF previously had agreed to work with, especially if the override is to approve a proposal. I understand that WMF might find a reason to decline a grant after committee approval because WMF finds something in its due diligence process that is unacceptable such as that the grantee has overdue reports on prior grants, but if a grantmaking committee develops consensus against a proposal and WMF approves it anyway, I think that is a problem, it shows a lack of trust, and it suggests that the WMF isn't serious about its own grantmaking process. As Alex explained above, the committee's role is advisory (to both WMF and applicants) and implicit in that is that its opinions -- while always taken carefully into account -- can and (rarely) will be in opposition to the final decision. That's been the committee's design from the start, and we are not breaking any agreement (as you seem to imply by previously had agreed to work with) in doing so. We are doing our job. Also contrary to what you say, we are yet to approve a proposal against which the committee has develop[ed] consensus. Take another look at the examples you brought yourself -- one oppose vote in a committee of 28 does not consensus make. I appreciate the flexibility of GAC's process but apparently the current system is not working, as everyone seems to agree. I disagree. In fact no one agrees the system is not working, as far as I can tell, except you. On the contrary the system, i.e. the Project and Event Grants program, is working fairly well, _despite_ a less-than-desired level of participation in its advisory committee. While that is certainly something we are endeavoring to improve (recognizing, of course, it is ultimately up to the committee members, but we can improve ways and means), it should not be taken to mean the system is not working. I am curious, what alternatives are you exploring? You are welcome to read all about it[1][2][3]. Cheers, Asaf [1] https://meta.wikimedia.org/wiki/Grants:PEG/Grant_Advisory_Committee/Revamp [2] https://meta.wikimedia.org/wiki/Grants_talk:PEG/Grant_Advisory_Committee/Revamp [3] https://meta.wikimedia.org/wiki/Grant_Advisory_Committee/Revamp_Discussion -- Asaf Bartov Wikimedia Foundation http://www.wikimediafoundation.org Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us make it a reality! https://donate.wikimedia.org ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Re: [Wikimedia-l] Community RfCs about MediaViewer
Just a note that I am drafting a request to the Board about governance of WMF product launches. Similar problems have happened enough times that I think the Board needs to step in with a more active role. I am also taking a look at the policies around office actions as they relate to product launches, and will likely request that the Board examine that policy as well. Pine On Thu, Jul 10, 2014 at 11:53 PM, Erik Moeller e...@wikimedia.org wrote: On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jay...@gmail.com wrote: Or .. sometimes the licensing and attribution information isnt correct In the common case, Media Viewer provides more prominent and appropriate attribution and license information than the File: page. The author name, license, license URL, and source URL are all immediately accessible below the image, whereas on the File: page there are sometimes screenfuls of metadata between the image and this crucial information. This is actually a pretty remarkable accomplishment given that this information comes from a huge number of different templates that vary across wikis. Media Viewer makes use of standardized CSS classes to extract metadata, and the team has actively worked with the community to broaden their use: http://lists.wikimedia.org/pipermail/multimedia/2014-March/000135.html Ultimately we'll want to use proper structured data for this, but these changes lay the groundwork, and there's already an API (used by Media Viewer but open to anyone) that exposes this information. Where no license is detected, Media Viewer still falls back to a View license link. The more problematic cases are where actual errors occur and important information is not extracted, and there will certainly inevitably be some cases where this happens, but this can only be worked on over time. The expectation that an unbounded problem like this is completely solved prior to deployment of a feature is unreasonable -- it's similar to TemplateData, in that the positive feedback loop into Media Viewer should actually help encourage more and consistent use of machine-readable data. sometimes you get resolutions which are silly (especially svgs at launch, but also slideshows on a file page include a very large license logo) Can you give a specific, current example? it takes extra clicks to get to the full-size version, It takes exactly one click using the View original file button. 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Thank you Mobile team
While we're talking about technology issues on WIkimedia-l, I'd like to say that now that I've worked my way over a few speedbumps with mobile editing I'm happy with the direction that mobile editing is going, so thank you Mobile team. 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Deprecating print-on-demand functionality
Thank you for the update, and thanks to Pediapress for the collaboration! I always liked to have the option, but indeed never was tempted enough to actually order something. Good to learn that the pdf function remains, that's great too! Lodewijk 2014-07-11 0:38 GMT+02:00 Thomas Gries m...@tgries.de: Am 11.07.2014 00:25, schrieb Erik Moeller: Since 2008, we've offered a small feature to download printed books from Wikipedia article. This is done in partnership with a company called PediaPress. They've sold about 15K books over that time period, not enough to break even, and the support/maintenance burden for the service is no longer worth it for them. We'll disable this feature in coming weeks. It's a pity, as I liked that service/very much/, it was quick, reliable, perfect quality, not too expensive. The only feature what I missed was the inability to add further PDF pages. We'd only continue to offer it if there's 1) strong community interest in maintaining it, and 2) a partner who steps up to provide the service. We'll continue to provide PDF downloads (soon with a new rendering engine). Thanks, Erik ___ Wikitech-l mailing list wikitec...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Thank you Mobile team
2014-07-11 10:06 GMT+02:00 Pine W wiki.p...@gmail.com: While we're talking about technology issues on WIkimedia-l, I'd like to say that now that I've worked my way over a few speedbumps with mobile editing I'm happy with the direction that mobile editing is going, so thank you Mobile team. +1 I also want to add, that I'm happy with the Visual Editor. It's not perfect, but for basic editing it works just fine. I've had very nice feedback from new user during training on how Visual Editor works. 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-requ...@lists.wikimedia.org?subject=unsubscribe -- Pierre-Selim ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
I agree with Erik here. Media Viewer may have some bugs that need to be fixed. But there are plenty of issues in other places too (like license tags). They also need to improved. See this ongoing discussion. [1] See my comment on RfC on Commons. [2] Jee Links: 1. https://commons.wikimedia.org/wiki/Commons:Village_pump/Copyright#Propose_to_update_CC_license_tags_to_comply_with_the_new_wordings_in_CC_deeds 2. https://commons.wikimedia.org/w/index.php?title=Commons:Requests_for_comment/Media_Viewer_software_featurediff=128434830oldid=128433051 On Fri, Jul 11, 2014 at 1:20 PM, Pine W wiki.p...@gmail.com wrote: Just a note that I am drafting a request to the Board about governance of WMF product launches. Similar problems have happened enough times that I think the Board needs to step in with a more active role. I am also taking a look at the policies around office actions as they relate to product launches, and will likely request that the Board examine that policy as well. Pine On Thu, Jul 10, 2014 at 11:53 PM, Erik Moeller e...@wikimedia.org wrote: On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jay...@gmail.com wrote: Or .. sometimes the licensing and attribution information isnt correct In the common case, Media Viewer provides more prominent and appropriate attribution and license information than the File: page. The author name, license, license URL, and source URL are all immediately accessible below the image, whereas on the File: page there are sometimes screenfuls of metadata between the image and this crucial information. This is actually a pretty remarkable accomplishment given that this information comes from a huge number of different templates that vary across wikis. Media Viewer makes use of standardized CSS classes to extract metadata, and the team has actively worked with the community to broaden their use: http://lists.wikimedia.org/pipermail/multimedia/2014-March/000135.html Ultimately we'll want to use proper structured data for this, but these changes lay the groundwork, and there's already an API (used by Media Viewer but open to anyone) that exposes this information. Where no license is detected, Media Viewer still falls back to a View license link. The more problematic cases are where actual errors occur and important information is not extracted, and there will certainly inevitably be some cases where this happens, but this can only be worked on over time. The expectation that an unbounded problem like this is completely solved prior to deployment of a feature is unreasonable -- it's similar to TemplateData, in that the positive feedback loop into Media Viewer should actually help encourage more and consistent use of machine-readable data. sometimes you get resolutions which are silly (especially svgs at launch, but also slideshows on a file page include a very large license logo) Can you give a specific, current example? it takes extra clicks to get to the full-size version, It takes exactly one click using the View original file button. 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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
Sue, You have gotten your logic exactly backwards here. Of course David is right -- we should all have some humility about things that we don't, and can't, know. But the people who express certainty about what readers need -- the people who assert that those needs are paramount, and trump the needs of editors (experienced and occasional), of photographers (with and without Wikimedia accounts), of models (consenting and non-consenting) -- and maybe most significantly, the people who have both the power and the audacity to impose their interpretation of those believes on millions upon millions upon millions of Wikimedia users -- those people all work for the Wikimedia Foundation. You're addressing the wrong audience here. -Pete [[User:Peteforsyth]] On Thu, Jul 10, 2014 at 9:40 PM, Sue Gardner sgard...@wikimedia.org wrote: Hey guys, I use MediaViewer, I like it, and I am happy to trust the WMF product team to build stuff. I didn't know about the RFC, but even if I had I would've been unlikely to have participated, because I don't think small opt-in discussions are the best way to do product development -- certainly not at the scale of Wikipedia. I think we should aim on this list to be modest rather than overreaching in terms of what we claim to know, and who we imply we're representing. It's probably best to be clear --both in the mails we write and in our own heads privately-- that what's happening here is a handful of people talking on a mailing list. We can represent our own opinions, and like David Gerard we can talk anecdotally about what our friends tell us. But I don't like it when people here seem to claim to speak on behalf of editors, or users, or readers, or the community. It strikes me as hubristic. Thanks, Sue On 10 Jul 2014 16:13, MZMcBride z...@mzmcbride.com wrote: Erik Moeller wrote: In this case, we will keep the feature enabled by default (it's easy to turn off, both for readers and editors), but we'll continue to improve it based on community feedback (as has already happened in the last few weeks). Thanks for the reply. :-) If your feature development model seemingly requires forcing features on users, it's probably safe to say that it's broken. If you're building cool new features, they will ideally be uncontroversial and users will actively want to enable them and eventually have them enabled by default. Many new features (e.g., the improved search backend) are deployed fairly regularly without fanfare or objection. But I see a common thread among unsuccessful deployments of features such as ArticleFeedbackv5, VisualEditor, and MediaViewer. Some of it is the people involved, of course, but the larger pattern is a fault in the process, I think. I wonder how we address this. MZMcBride ___ 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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Thank you Mobile team
+1 I've been doing wiki workshops for Amical during last couple of years and since 6 months ago or so I ONLY train newbies with the visual editor. My role on the workshop now is reduced to explain how extra features are done. So kudos to the mobile team. And I know is not perfect. Is just wiki ;) 2014-07-11 10:16 GMT+02:00 Pierre-Selim pierre-se...@huard.info: 2014-07-11 10:06 GMT+02:00 Pine W wiki.p...@gmail.com: While we're talking about technology issues on WIkimedia-l, I'd like to say that now that I've worked my way over a few speedbumps with mobile editing I'm happy with the direction that mobile editing is going, so thank you Mobile team. +1 I also want to add, that I'm happy with the Visual Editor. It's not perfect, but for basic editing it works just fine. I've had very nice feedback from new user during training on how Visual Editor works. 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-requ...@lists.wikimedia.org?subject=unsubscribe -- Pierre-Selim ___ 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
There is now. There wasn't originally, or if there was, it didn't show up for me. That was one of the main initial problems, and that's pretty basic stuff. I already figured out how to get rid of it, but it took a good deal of digging at the time to even find out that I could. So, yes, it's good there's a disable button there. That restores my workflow personally. That doesn't, however, help the concern that millions of users are pulling up the images without immediately seeing the license requirements and author information. The majority of our images require attribution. Some are even nonfree, and which ones may not be clear at first glance. It also doesn't solve the concern that the tool is not yet ready for prime time and shouldn't be the default user experience. On Fri, Jul 11, 2014 at 12:48 AM, Risker risker...@gmail.com wrote: There's a easy, clearly accessible, one-click option for disabling MediaViewer, Todd. Scroll to the bottom of the screen. Click disable. Done - it automatically changes your preference. Risker/Anne On 11 July 2014 02:44, Todd Allen toddmal...@gmail.com wrote: Risker, I'm actually not going to disagree with you in principle. I ultimately see Media Viewer being used by a good number of users, and said as much from the start. But I also warned that a bulldozer approach was going to cause massive blowback, especially after the previous debacles (VE and ACTRIAL come to mind for me). And well, here we are, with another repeat of the VE situation. That greatly eroded trust in WMF, especially its dev teams and PMs, and that's nowhere even close to rebuilt yet. Now that lack of trust is being confirmed and entrenched. WMF needs to step very lightly with deployments that will affect editors, and treat the volunteer community as an ally rather than adversary. If that doesn't happen, these showdowns will keep happening. Part of that is pure arrogance. A significant part of the reason the Vector switch worked is because there was an easy, clearly accessible, one-click option that said Do not want, disable this!. If that'd been the case here, I would have clicked that and forgotten about it. Instead, I had to dig for an hour to find how to disable the thing, after being surprised by a totally unexpected change. But now we hear things like We made Vector opt-out too easy! Media Viewer probably does have its place, once it is fully functional and free of major bugs. I might even turn it on at that point. But shoving it down people's throats will only serve to further place the WMF's flagship project and the WMF at odds. That is not, I can't imagine, a desirable situation by anyone's estimation. WMF needs a far better deployment strategy than YOU ARE GETTING IT, LIKE IT OR NOT, AND THAT IS FINAL! If the WMF's strategy for when the core community and dev team disagree is We're right, you're wrong, pipe down, these situations will increase in frequency and intensity. I want to stop that before it reaches a real boiling point, and it could've this time if someone had actually gotten desysopped. On Fri, Jul 11, 2014 at 12:21 AM, Risker risker...@gmail.com wrote: While I'm not necessarily disagreeing with you, Todd, there were 14,681 users on English Wikipedia alone who had enabled MediaViewer using the Beta Features preference before it became the default. That's a huge number of people who were all using it every time they clicked on an image in the weeks and months beforehand, and every one of them had to make a conscious decision to turn it on. The 64 users who want it disabled as default pale in comparison to the number of people who were actively using it beforehand. I've asked for some better statistical information because I don't think the Limn graphs that have been referred to in the discussion of the RFC are really accurate; it's my understanding that about 1600 registered accounts have opted out of MV in total (this should be a linear graph of the cumulative total, not a daily number of people who opted out graph which is what we seem to see now). As well, somewhere in the neighbourhood of 500 logged out users a day are disabling it - this needs to be a daily number, not a cumulative one, because logged-out disabling is linked to the individual browser session; those who aren't logged in don't have the chance to set preferences. There are between 4 and 5 *million* clicks on image thumbnails every day on enwiki, with only around 500 of those viewing the images disabling the MediaViewer (excluding logged-in users who have turned it off in their preferences). I suspect that at the end of the day, MediaViewer is going to be more like the switch to Vector skin: there will be plenty of people who choose to disable for reasons that work for them, but the overwhelming majority of
Re: [Wikimedia-l] Community RfCs about MediaViewer
'On Fri, Jul 11, 2014 at 4:53 PM, Erik Moeller e...@wikimedia.org wrote:
On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jay...@gmail.com
wrote:
Or .. sometimes the licensing and attribution information isnt
correct
In the common case, Media Viewer provides more prominent and
appropriate attribution and license information than the File: page.
The author name, license, license URL, and source URL are all
immediately accessible below the image, whereas on the File: page
there are sometimes screenfuls of metadata between the image and this
crucial information.
Im not suggesting that the layout of MV isnt great, but that isnt the
issue I raised, and you are unfortunately very wrong and dumbing the
licensing and attribution information down is fraught with problems
that need to be carefully worked through,
Let's walk through a real example, of a page with over half a milion
page views in the last two days.
https://en.wikipedia.org/wiki/Indonesian_presidential_election,_2014
http://stats.grok.se/en/latest/Indonesian_presidential_election,_2014
The photo of Prabowo in MV has a caption of 'Prabowo wapres' instead
of 'Prabowo Subianto' which is (now) the caption and alt text on the
enwiki article, and the the Jokowi photo in MV has a caption of
'Gubernur DKI Jokowi' despite having an {{information}} block on
Commons with an English Indonesian descriptions, albeit without
perfect syntax, but that is par for the course and MV design needs to
cater for this type of scenario.
Scrolling down on the Prabowo image in MV shows '== Licensing: ==' ..
whoops wasnt wikitext supposed to be hidden? This is another syntax
problem with the wikitext, but our goal should be to show broken
wikitext to as many eyes as possible so that one person takes the
initiative to try to fix it. The licensing shows 'CC-BY-SA 3.0', but
the image is 'correctly' tagged as CC GFDL. The Commons Slideshow
gadget manages to correctly detect that this image has metadata that
says it is dual licensed. Try
https://commons.wikimedia.org/wiki/Help:Slideshow on
https://commons.wikimedia.org/wiki/Category:Prabowo_Subianto . Why
does the opt-in slideshow gadget have a better understanding of media
metadata than the WMF opt-out media viewer?
Scrolling down on the Jokowi image in MV shows Indonesian text instead
of English text, it isnt identified as Indonesian language despite
very good syntax in the wikitext, and the 'License details' block on
my screen shows the first two lines of the licensing template, and the
top third of the third line of text which makes it unreadable, and a
'View more' sort-of-button which appears at the bottom right also
overlapping with the second line of license text, obscuring that also.
I can expand the box to show the rest of the license details, but ..
eww .. this is out of beta really??
From an ideology perspective, these image pages have many issues which
needed to be edited, and the MV doesnt promote editing. It shows
dubious, incorrect, or syntactically invalid metadata as if it is
un-editable, instead of suggesting that the metadata needs editing.
It doesnt highlight that one of these images is claimed to be a CC
photo , yet it is a professional shot, is uploaded by someone with a
red username. Our astute image reusers should be looking for an OTRS
permission tag, which is missing.
The slidebar has a sequence which repeats the images: Probowo -
Jokowi - Prabowo - Jokowi - Prabowo - Jowoki and then whooping
huge Indonesia flag colors.
I could easily double or triple what I have written above about just
that one page, focusing on finer details of the MV UI that are poor
design or inadequate implementation, but .. sigh .. you have people
paid to do your designs.
And, there are also sorts of quite important parts of the licensing
process which are ignored by MV.
e.g. a image which is OTRS pending, now doesnt include a big scary
warning one click away.
https://en.wikipedia.org/wiki/Nick_Driver#mediaviewer/File:Nick_Driver_in_2013.png
Erik, do you know what percentage of image pages are not correctly
parsed and presented by MV wrt licensing and attribution?
This is actually a pretty remarkable accomplishment given that this
information comes from a huge number of different templates that vary
across wikis. Media Viewer makes use of standardized CSS classes to
extract metadata, and the team has actively worked with the community
to broaden their use:
http://lists.wikimedia.org/pipermail/multimedia/2014-March/000135.html
Ultimately we'll want to use proper structured data for this, but
these changes lay the groundwork, and there's already an API (used by
Media Viewer but open to anyone) that exposes this information.
Where no license is detected, Media Viewer still falls back to a View
license link. The more problematic cases are where actual errors
occur and important information is not extracted, and there will
certainly inevitably be some cases where this happens, but this
Re: [Wikimedia-l] [Wikitech-ambassadors] Deprecating print-on-demand functionality
On Fri, Jul 11, 2014 at 8:45 AM, Luca Martinelli martinellil...@gmail.com wrote: so the Book Creator will still be active, maybe under another name, maybe with another engine, but still active? Same name and functionality, just the Order a printed book feature will disappear. 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 10/07/2014, Erik Moeller e...@wikimedia.org wrote: On Wed, Jul 9, 2014 at 10:03 PM, Pine W wiki.p...@gmail.com wrote: Will WMF deactivate MediaViewer on English Wikipedia No. Detailed explanation: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Media_Viewer/June_2014_RfCdiff=616407785oldid=616294249 Folks following this discussion, and the problematic tone we have seen from some parties, may want to chip in with their views for the English Wikipedia Arbcom to consider: https://en.wikipedia.org/wiki/Wikipedia:Arbitration/Requests/Case#MediaViewer_RfC Fae -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae https://en.wikipedia.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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Fri, Jul 11, 2014 at 4:21 AM, John Mark Vandenberg jay...@gmail.com wrote:
https://en.wikipedia.org/wiki/Indonesian_presidential_election,_2014
http://stats.grok.se/en/latest/Indonesian_presidential_election,_2014
The photo of Prabowo in MV has a caption of 'Prabowo wapres'
This happens to be the file's name, which is also the first thing
users see when they visit the File: page. Media Viewer uses filenames
for the titles because there is no consistently short
description/label available. It's been suggested to potentially move
the caption (when available, which it often won't be, or not in the
correct language) below the image instead, but this would lead to a
more inconsistent experience and would require making the font size
significantly smaller. In any case, it's something we can continue to
discuss. Fabrice's preference is to wait for the implementation of
structured data support for file description pages, and to then use a
multilingual title field (similar to the label for Wikidata items).
instead of 'Prabowo Subianto' which is (now) the caption and alt text on the
enwiki article, and the the Jokowi photo in MV has a caption of
'Gubernur DKI Jokowi' despite having an {{information}} block on
Commons with an English Indonesian descriptions, albeit without
perfect syntax, but that is par for the course and MV design needs to
cater for this type of scenario.
In this case it's doing the right thing -- pulling the only
description that has a language tag set. Pulling the surrounding text
as the default would likely be worse in far more situations. Media
Viewer respects the ?uselang= parameter and will show the description
in the desired language if available.
Scrolling down on the Prabowo image in MV shows '== Licensing: ==' ..
whoops wasnt wikitext supposed to be hidden?
You mean like it is here?
https://en.wikipedia.org/wiki/File:Prabowo_wapres.jpeg
This is another syntax
problem with the wikitext, but our goal should be to show broken
wikitext to as many eyes as possible so that one person takes the
initiative to try to fix it.
The Wikimedia Foundation mission statement is not to show broken
wikitext to as many eyes as possible. Wikitext is a tool - and
ultimately this file metadata should be managed using a more
appropriate tool.
The licensing shows 'CC-BY-SA 3.0', but
the image is 'correctly' tagged as CC GFDL.
Whether or not Media Viewer should show _all_ licenses or just
highlight the most usable one is a reasonable discussion to have.
Right now, it attempts to do the latter. IMO it should probably
recommend a default license above the fold, and show all others below
the fold.
GFDL is a license that requires re-users to include a full printed
copy of the text of the license with an image. It's nice that we're
offering it for some images in addition to CC-licenses, but except for
some very obscure cases, it seems unlikely that any user would
actually ever _need_ it. So offering this information in a less
prominent fashion seems appropriate.
Scrolling down on the Jokowi image in MV shows Indonesian text instead
of English text, it isnt identified as Indonesian language despite
very good syntax in the wikitext
Media Viewer will pick the most suitable available tagged language and
render it. It might be useful to identify a non-English language as
such to guide viewers -- I'll file an enhancement request for that. As
noted previously, because Indonesian is the only language that was
tagged, it will pick that one. I've edited the file description to tag
English:
https://commons.wikimedia.org/wiki/File:Gubernur_DKI_Jokowi.jpg#mediaviewer/File:Gubernur_DKI_Jokowi.jpg
And here it is in Indonesian:
https://commons.wikimedia.org/wiki/File:Gubernur_DKI_Jokowi.jpg?uselang=id#mediaviewer/File:Gubernur_DKI_Jokowi.jpg
and the 'License details' block on
my screen shows the first two lines of the licensing template, and the
top third of the third line of text which makes it unreadable, and a
'View more' sort-of-button which appears at the bottom right also
overlapping with the second line of license text, obscuring that also.
I can expand the box to show the rest of the license details, but ..
The fade-out indicates that the text is abbreviated and can be expanded.
From an ideology perspective, these image pages have many issues which
needed to be edited, and the MV doesnt promote editing. It shows
dubious, incorrect, or syntactically invalid metadata as if it is
un-editable, instead of suggesting that the metadata needs editing.
Yes - we definitely want to offer editing functionality in the viewer
down the road. This is directly tied to the work on structured data.
When fields like titles are stored as structured metadata, we can
potentially make them editable with a simple click action -- even
translatable! However, it would be unwise to build such functionality
now on top of wikitext. (We should determine whether we really want to
expose editing
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 11 July 2014 00:40, Erik Moeller e...@wikimedia.org wrote: change-aversion tends to correlate pretty strongly with impact on existing workflows and noticeable changes to user experience and behavior. It's interesting to read that claim in the content of my aversion to the unexpected removal of the very useful 'nearby' feature from the Android app [1]. It's normal and expected that the first reaction to noticeable user experience changes will often be negative. I've yet to hear of any positive aspects of that removal. [1] Promoted by the WMF at the time of its launch: http://blog.wikimedia.org/2013/05/29/wikipedia-nearby-beta/ and widely reported in the press. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmal...@gmail.com wrote: That doesn't, however, help the concern that millions of users are pulling up the images without immediately seeing the license requirements and author information. To the contrary, Media Viewer displays the license, author and source as an always visible part of the image. On a typical file page, you have to scroll down to find any of this information; most users won't do that, if what they are looking for is the image, and that is available without scrolling. (It is well known in web usability http://www.nngroup.com/articles/scrolling-and-attention/ that relatively little attention is given to things above the fold; one of the main benefits of Media Viewer is that it brings the most important things above it.) Also, many people might not use file pages simply because they are so slow. A famous experiment by Google http://googleresearch.blogspot.com/2009/06/speed-matters.html showed that lowering loading speed by 200 ms resulted in 0.3% less interactions (on the English Wikipedia's scale, that would be about 20,000 thumbnail clicks a day). MediaViewer improves image loading time by a full second for the median user. ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Proposal: List administration policy
Hi Fae, I was banned from the list by Austin Hair. I had contributed in my view a lot of good and polite stuff that was reasonably reasoned, but he banned me on the basis of a 17-word parenthetical phrase regarding arbitrator Timotheus Canens. I said that I had read it claimed that he was connected to Chinese military intelligence. Is that a reason to ban me? I emailed him, and then repeat emailed him to talk to me about it. I was met by silence. I wasn't going to get upset about it, and didn't. I figure Austin just another type who got moderator privilege on a mailing list. It's not even worth it to criticize him, but I guess I'll notice he banned me within minutes, and he hasn't posted to the list anything since, and I don't recall him ever contributing a email of substantive opinion since I joined the list. I logged on here today with the aim of unsubscribing to the list, but I'll keep reading long enough to see if your below email asking for transparency on the list goes anywhere. Good luck. Trillium Corsage 11.07.2014, 11:28, Fæ fae...@gmail.com: Hi, I would like to propose that this list have a published process for post moderation, banning and appeals. Perhaps a page on meta would be a good way to propose and discuss a policy? I would be happy to kick off a draft. This list has a defined scope at https://lists.wikimedia.org/mailman/listinfo/wikimedia-l which explains who the 3 list admins are, but no more than that. There is no system of appeals, no expected time limits on bans or moderation, nor an explanation of the 30 posts per month behavioural norm that sometimes applies to this list. Neither is there any explanation of what is expected of list admins, such as whether there is an obligation to explain to someone who finds themselves subject to moderation or a ban, as to why this has happened and what they ought to do in order to become un-banned or un-moderated. I believe this would help list users better understand what is expected of them when they post here and it may give an opportunity to review the transparency of list administration, such as the option of publishing a list of active moderated accounts and possibly a list of indefinitely banned accounts where these were for behaviour on the list (as opposed to content-free spamming etc.) I see no down side to explaining policy as openly as possible. Thoughts? Fae -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae (P.S. I am active on the English Wikipedia where I have a GA on the go, see https://en.wikipedia.org/wiki/User:Fae. Sorry to disappoint, but reports of my retirement are premature.) ___ 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Proposal: List administration policy
Actually, Trillium Corsage, I'd say that's a reason for banning you again. It's a very serious allegation you're implying about a longstanding member of our community. Risker On 11 July 2014 14:24, Trillium Corsage trillium2...@yandex.com wrote: Hi Fae, I was banned from the list by Austin Hair. I had contributed in my view a lot of good and polite stuff that was reasonably reasoned, but he banned me on the basis of a 17-word parenthetical phrase regarding arbitrator Timotheus Canens. I said that I had read it claimed that he was connected to Chinese military intelligence. Is that a reason to ban me? I emailed him, and then repeat emailed him to talk to me about it. I was met by silence. I wasn't going to get upset about it, and didn't. I figure Austin just another type who got moderator privilege on a mailing list. It's not even worth it to criticize him, but I guess I'll notice he banned me within minutes, and he hasn't posted to the list anything since, and I don't recall him ever contributing a email of substantive opinion since I joined the list. I logged on here today with the aim of unsubscribing to the list, but I'll keep reading long enough to see if your below email asking for transparency on the list goes anywhere. Good luck. Trillium Corsage 11.07.2014, 11:28, Fæ fae...@gmail.com: Hi, I would like to propose that this list have a published process for post moderation, banning and appeals. Perhaps a page on meta would be a good way to propose and discuss a policy? I would be happy to kick off a draft. This list has a defined scope at https://lists.wikimedia.org/mailman/listinfo/wikimedia-l which explains who the 3 list admins are, but no more than that. There is no system of appeals, no expected time limits on bans or moderation, nor an explanation of the 30 posts per month behavioural norm that sometimes applies to this list. Neither is there any explanation of what is expected of list admins, such as whether there is an obligation to explain to someone who finds themselves subject to moderation or a ban, as to why this has happened and what they ought to do in order to become un-banned or un-moderated. I believe this would help list users better understand what is expected of them when they post here and it may give an opportunity to review the transparency of list administration, such as the option of publishing a list of active moderated accounts and possibly a list of indefinitely banned accounts where these were for behaviour on the list (as opposed to content-free spamming etc.) I see no down side to explaining policy as openly as possible. Thoughts? Fae -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae (P.S. I am active on the English Wikipedia where I have a GA on the go, see https://en.wikipedia.org/wiki/User:Fae. Sorry to disappoint, but reports of my retirement are premature.) ___ 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-requ...@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/guidelineswikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Board decision on FDC member appointments
Dear friends: We are pleased to inform you that the WMF Board of Trustees has come to a decision about which four candidates to appoint to the FDC. It wasn't easy; as is evident from the nominations, the caliber of the candidates was very high. The resolution is now published in https://wikimediafoundation.org/wiki/Resolution:Funds_Dissemination_Committee_Membership_2014 We have selected four appointees as follows: 1)Anne Clin (Risker) 2)Matanya Moses (matanya) 3)Dumisani Ndubane (Thuvack) 4)Osmar Valdebenito (B1mbo) On behalf of the Board, we want to thank Anders, Arjuna, Mike and Yuri for their service to the inaugural FDC. We deeply appreciate the two years they have served the committee and all the work they have done during four rounds of FDC recommendations. They have helped to shape the FDC itself, made critical decisions about how to strategically direct movement funds, and helped to shape the future of the movement. We hope they will continue to remain engaged in the FDC process and the movement in different ways in the years ahead. We also want to thank all the candidates, and encourage them to consider re-applying for the committee next year, when five new members will be elected to serve on the committee. Best, Bishakha and Patricio -- Patricio Lorente Blog: http://www.patriciolorente.com.ar Identi.ca // Twitter: @patriciolorente ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Board decision on FDC member appointments
Il 11/lug/2014 22:07 Patricio Lorente patricio.lore...@gmail.com ha scritto: Dear friends: We are pleased to inform you that the WMF Board of Trustees has come to a decision about which four candidates to appoint to the FDC. It wasn't easy; as is evident from the nominations, the caliber of the candidates was very high. The resolution is now published in https://wikimediafoundation.org/wiki/Resolution:Funds_Dissemination_Committee_Membership_2014 We have selected four appointees as follows: 1)Anne Clin (Risker) 2)Matanya Moses (matanya) 3)Dumisani Ndubane (Thuvack) 4)Osmar Valdebenito (B1mbo) On behalf of the Board, we want to thank Anders, Arjuna, Mike and Yuri for their service to the inaugural FDC. We deeply appreciate the two years they have served the committee and all the work they have done during four rounds of FDC recommendations. They have helped to shape the FDC itself, made critical decisions about how to strategically direct movement funds, and helped to shape the future of the movement. We hope they will continue to remain engaged in the FDC process and the movement in different ways in the years ahead. We also want to thank all the candidates, and encourage them to consider re-applying for the committee next year, when five new members will be elected to serve on the committee. Welcome to the new members and thanks to everybody involved in the process. Thanks a lot to everyone in the nominations. Cristian ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Android Nearby Feature (was: Re: Community RfCs about MediaViewer)
On Fri, Jul 11, 2014 at 10:37 AM, Andy Mabbett a...@pigsonthewing.org.uk wrote: It's interesting to read that claim in the content of my aversion to the unexpected removal of the very useful 'nearby' feature from the Android app [1]. (...) [1] Promoted by the WMF at the time of its launch: http://blog.wikimedia.org/2013/05/29/wikipedia-nearby-beta/ and widely reported in the press. Apologies for the thread-split, but this is OT from the original thread. This blog post actually referred to the Mobile Web, where the feature continues to be available (without a map view): http://en.m.wikipedia.org/wiki/Special:Nearby The new Android app isn't simply an upgrade of the last version, it's a complete re-write in native code -- one which by all accounts has been extremely well received. In determining the feature set, the team looked at core functionality they really wanted to deliver in the first release, and iterated on that based on user feedback during the beta. We are in the lucky position to now have a team of three full-time developers working on the app to make it continually better. You can see the most recent code changes here: https://gerrit.wikimedia.org/r/#/q/apps/android,n,z And a more understandable view of the current sprint in Trello: https://trello.com/b/5DhKhjmW/mobile-app-sprint-35-article-usability-enhancements So you can expect a pretty fast pace of change. The team prioritized features that were highly requested and popular among users. The nearby feature in the old app also relied on third party infrastructure, which makes us a bit uncomfortable from a user privacy and principles perspective. Our plan is to build out our own OpenStreetMap infrastructure later this year which will help in further developing such geo-functionality. CCing Dan (PM for Apps) in case he wants to weigh in on the roadmap. 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Android Nearby Feature (was: Re: Community RfCs about MediaViewer)
The current mobile site and the current Android app reflect a major step backward in terms of attributing the authors of Wikipedia content. In February 2012, I initiated discussions that resulted in both the mobile site and the Android app clearly stating in the footer that the content was written by volunteers like you, with a link to the page history, and thereby, the user accounts of all users. https://bugzilla.wikimedia.org/show_bug.cgi?id=34673 https://bugzilla.wikimedia.org/show_bug.cgi?id=35616 While a mere link to the desktop site's history screen was considered sufficient, by the WMF's then-general counsel, to meet the letter of the law (of the CC BY-SA license), what we discussed in those tickets was how the WMF could exceed what is legally required, in order to demonstrate to the world what it looks like to properly attribute the contributors of content who require attribution as part of their choice to create content for free. In those 2012 discussions, WMF staff also acknowledged that there were benefits to going even further in that direction, by pulling the page history into the mobile view/app itself. However, in 2014, both the mobile site and the Android app have footers that lack any mention of the authors of the article, merely inserting a link that says: Desktop (on the mobile site, which is still a click away from history) and Last updated June 29 (on the Android app). Is the WMF is serious about honoring the copyright licenses Wikipedia's contributors work under, which require attribution, both technically and in spirit? Pete [[User:Peteforsyth]] On Fri, Jul 11, 2014 at 2:34 PM, Erik Moeller e...@wikimedia.org wrote: On Fri, Jul 11, 2014 at 10:37 AM, Andy Mabbett a...@pigsonthewing.org.uk wrote: It's interesting to read that claim in the content of my aversion to the unexpected removal of the very useful 'nearby' feature from the Android app [1]. (...) [1] Promoted by the WMF at the time of its launch: http://blog.wikimedia.org/2013/05/29/wikipedia-nearby-beta/ and widely reported in the press. Apologies for the thread-split, but this is OT from the original thread. This blog post actually referred to the Mobile Web, where the feature continues to be available (without a map view): http://en.m.wikipedia.org/wiki/Special:Nearby The new Android app isn't simply an upgrade of the last version, it's a complete re-write in native code -- one which by all accounts has been extremely well received. In determining the feature set, the team looked at core functionality they really wanted to deliver in the first release, and iterated on that based on user feedback during the beta. We are in the lucky position to now have a team of three full-time developers working on the app to make it continually better. You can see the most recent code changes here: https://gerrit.wikimedia.org/r/#/q/apps/android,n,z And a more understandable view of the current sprint in Trello: https://trello.com/b/5DhKhjmW/mobile-app-sprint-35-article-usability-enhancements So you can expect a pretty fast pace of change. The team prioritized features that were highly requested and popular among users. The nearby feature in the old app also relied on third party infrastructure, which makes us a bit uncomfortable from a user privacy and principles perspective. Our plan is to build out our own OpenStreetMap infrastructure later this year which will help in further developing such geo-functionality. CCing Dan (PM for Apps) in case he wants to weigh in on the roadmap. 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Proposal: List administration policy
I think it is very difficult to have hard 'rules'. The guidelines have been published and are referred to in the footer of each messages sent from this list. https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines I have added a link to these to the list info page at https://meta.wikimedia.org/wiki/Wikimedia-l and will transfer it to the list info page if there is no objection. Regards, Richard. On 11/07/14 20:28, Fæ wrote: Hi, I would like to propose that this list have a published process for post moderation, banning and appeals. Perhaps a page on meta would be a good way to propose and discuss a policy? I would be happy to kick off a draft. This list has a defined scope at https://lists.wikimedia.org/mailman/listinfo/wikimedia-l which explains who the 3 list admins are, but no more than that. There is no system of appeals, no expected time limits on bans or moderation, nor an explanation of the 30 posts per month behavioural norm that sometimes applies to this list. Neither is there any explanation of what is expected of list admins, such as whether there is an obligation to explain to someone who finds themselves subject to moderation or a ban, as to why this has happened and what they ought to do in order to become un-banned or un-moderated. I believe this would help list users better understand what is expected of them when they post here and it may give an opportunity to review the transparency of list administration, such as the option of publishing a list of active moderated accounts and possibly a list of indefinitely banned accounts where these were for behaviour on the list (as opposed to content-free spamming etc.) I see no down side to explaining policy as openly as possible. Thoughts? 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Android Nearby Feature (was: Re: Community RfCs about MediaViewer)
On Fri, Jul 11, 2014 at 3:02 PM, Pete Forsyth petefors...@gmail.com wrote: The current mobile site and the current Android app reflect a major step backward in terms of attributing the authors of Wikipedia content. In February 2012, I initiated discussions that resulted in both the mobile site and the Android app clearly stating in the footer that the content was written by volunteers like you, with a link to the page history, and thereby, the user accounts of all users. https://bugzilla.wikimedia.org/show_bug.cgi?id=34673 https://bugzilla.wikimedia.org/show_bug.cgi?id=35616 While a mere link to the desktop site's history screen was considered sufficient, by the WMF's then-general counsel, to meet the letter of the law (of the CC BY-SA license), what we discussed in those tickets was how the WMF could exceed what is legally required, in order to demonstrate to the world what it looks like to properly attribute the contributors of content who require attribution as part of their choice to create content for free. In those 2012 discussions, WMF staff also acknowledged that there were benefits to going even further in that direction, by pulling the page history into the mobile view/app itself. However, in 2014, both the mobile site and the Android app have footers that lack any mention of the authors of the article, merely inserting a link that says: Desktop (on the mobile site, which is still a click away from history) and Last updated June 29 (on the Android app). Pete, before making such strong public statements condemning our products, it might help to use them :) Both the new native apps and the mobile web site offer a mobile-friendly page history (like this one: https://en.m.wikipedia.org/wiki/Special:History/Babe_Ruth). On the apps it's accessible from the footer, and on the web view the link is given an extremely prominent place in the UI, at the top of all articles (the Last edited by.. line). I'd recommend you follow the WMF blog to stay abreast of our work on this and other mobile features, since we wrote about this back in May: http://blog.wikimedia.org/2014/05/02/the-wikipedia-editors-behind-the-curtain/ Is the WMF is serious about honoring the copyright licenses Wikipedia's contributors work under, which require attribution, both technically and in spirit? Pete [[User:Peteforsyth]] On Fri, Jul 11, 2014 at 2:34 PM, Erik Moeller e...@wikimedia.org wrote: On Fri, Jul 11, 2014 at 10:37 AM, Andy Mabbett a...@pigsonthewing.org.uk wrote: It's interesting to read that claim in the content of my aversion to the unexpected removal of the very useful 'nearby' feature from the Android app [1]. (...) [1] Promoted by the WMF at the time of its launch: http://blog.wikimedia.org/2013/05/29/wikipedia-nearby-beta/ and widely reported in the press. Apologies for the thread-split, but this is OT from the original thread. This blog post actually referred to the Mobile Web, where the feature continues to be available (without a map view): http://en.m.wikipedia.org/wiki/Special:Nearby The new Android app isn't simply an upgrade of the last version, it's a complete re-write in native code -- one which by all accounts has been extremely well received. In determining the feature set, the team looked at core functionality they really wanted to deliver in the first release, and iterated on that based on user feedback during the beta. We are in the lucky position to now have a team of three full-time developers working on the app to make it continually better. You can see the most recent code changes here: https://gerrit.wikimedia.org/r/#/q/apps/android,n,z And a more understandable view of the current sprint in Trello: https://trello.com/b/5DhKhjmW/mobile-app-sprint-35-article-usability-enhancements So you can expect a pretty fast pace of change. The team prioritized features that were highly requested and popular among users. The nearby feature in the old app also relied on third party infrastructure, which makes us a bit uncomfortable from a user privacy and principles perspective. Our plan is to build out our own OpenStreetMap infrastructure later this year which will help in further developing such geo-functionality. CCing Dan (PM for Apps) in case he wants to weigh in on the roadmap. 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-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org
Re: [Wikimedia-l] Android Nearby Feature (was: Re: Community RfCs about MediaViewer)
On Fri, Jul 11, 2014 at 3:33 PM, Maryana Pinchuk mpinc...@wikimedia.org wrote: On Fri, Jul 11, 2014 at 3:02 PM, Pete Forsyth petefors...@gmail.com wrote: The current mobile site and the current Android app reflect a major step backward in terms of attributing the authors of Wikipedia content. Pete, before making such strong public statements condemning our products, it might help to use them I'm using the most recent Mobile Web via Chrome on a recent version of Android, and the most recent version of the Android app in the Google Play app store. Perhaps there are newer versions of both somewhere in a pipeline somewhere, that address these concerns. I hope so. I don't think I did anything wrong, though, to be ignorant that the stuff currently being talked about is not yet live. And even if that is the case, it is disheartening to know that this lapsed between 2012 and 2014 without any notifications to those of us who participated in the Bugzilla tickets. Maybe that's past stuff not worth dredging up, but it doesn't exactly make me feel like my contributions or my time were valued. The impression is that my concerns were managed, not incorporated. 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Android Nearby Feature (was: Re: Community RfCs about MediaViewer)
To your specific points: On Fri, Jul 11, 2014 at 3:33 PM, Maryana Pinchuk mpinc...@wikimedia.org wrote: (like this one: https://en.m.wikipedia.org/wiki/Special:History/Babe_Ruth). Even once the reader gets there, how many clicks does it take to get to a contributor's User Page, where they might state things like their name, and what they like to work on? I went through about 4 clicks and gave up. On the apps it's accessible from the footer, and on the web view the link is given an extremely prominent place in the UI, at the top of all articles (the Last edited by.. line). IMO Last edited by does not indicate that there will be a list of all contributors. Did you do any user testing to see if people make that association? It sounds like a stretch, but I'd be interested to see relevant data. -Pete ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Android Nearby Feature (was: Re: Community RfCs about MediaViewer)
On Fri, Jul 11, 2014 at 5:48 PM, Pete Forsyth petefors...@gmail.com wrote: To your specific points: On Fri, Jul 11, 2014 at 3:33 PM, Maryana Pinchuk mpinc...@wikimedia.org wrote: (like this one: https://en.m.wikipedia.org/wiki/Special:History/Babe_Ruth). Even once the reader gets there, how many clicks does it take to get to a contributor's User Page, where they might state things like their name, and what they like to work on? I went through about 4 clicks and gave up. Two clicks from the mobile history page. Click on a diff, and then the userpage is linked in bright blue in the bottom left. Underneath that link is the user's total number of live edits, and you can thank a user for the edit with a button on the right. -- Keegan Peterzell Community Liaison, Product 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Android Nearby Feature (was: Re: Community RfCs about MediaViewer)
On Fri, Jul 11, 2014 at 5:58 PM, Keegan Peterzell kpeterz...@wikimedia.org wrote: On Fri, Jul 11, 2014 at 5:48 PM, Pete Forsyth petefors...@gmail.com wrote: To your specific points: On Fri, Jul 11, 2014 at 3:33 PM, Maryana Pinchuk mpinc...@wikimedia.org wrote: (like this one: https://en.m.wikipedia.org/wiki/Special:History/Babe_Ruth). Even once the reader gets there, how many clicks does it take to get to a contributor's User Page, where they might state things like their name, and what they like to work on? I went through about 4 clicks and gave up. Two clicks from the mobile history page. Click on a diff, and then the userpage is linked in bright blue in the bottom left. Underneath that link is the user's total number of live edits, and you can thank a user for the edit with a button on the right. My apologies, I misread you Pete. It's three clicks to talk to the user, four to get to the user page. -- Keegan Peterzell Community Liaison, Product 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Android Nearby Feature (was: Re: Community RfCs about MediaViewer)
On 11 July 2014 22:34, Erik Moeller e...@wikimedia.org wrote: The new Android app isn't simply an upgrade of the last version, it's a complete re-write in native code This technical nicety is of no interest to most users, whose app was updated. In determining the feature set, the team looked at core functionality they really wanted to deliver in the first release, and iterated on that based on user feedback during the beta. I didn't participate in this round of the beta, because there was no suggestion in anything that I read that significant - significantly useful - existing functionality would be removed. (Indeed, the removal wasn't mentioned when the revamped app was announced by your WMF colleagues.) I did, though, spend some time testing the nearby feature in v1's beta - and demonstrating it when promoting the app to audiences outside the Wikipedia community. In splitting this thread and describing it as off topic, you've overlooked that my comments were in the context of - and in response to - your comment about change-aversion [tending] to correlate pretty strongly with impact on existing workflows and noticeable changes to user experience and behaviour. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Android Nearby Feature (was: Re: Community RfCs about MediaViewer)
On 11 July 2014 22:34, Erik Moeller e...@wikimedia.org wrote: The new Android app isn't simply an upgrade of the last version, it's a complete re-write in native code This technical nicety is of no interest to most users, whose app was updated. In determining the feature set, the team looked at core functionality they really wanted to deliver in the first release, and iterated on that based on user feedback during the beta. I didn't participate in this round of the beta, because there was no suggestion in anything that I read that significant - significantly useful - existing functionality would be removed. (Indeed, the removal wasn't mentioned when the revamped app was announced by your WMF colleagues.) I did tough, spend some time testing the nearby feature in v1's beta And a more understandable view of the current sprint in Trello: https://trello.com/b/5DhKhjmW/mobile-app-sprint-35-article-usability-enhancements I can't find the string near on that page. The nearby feature in the old app also relied on third party infrastructure, which makes us a bit uncomfortable from a user privacy and principles perspective. Our plan is to build out our own OpenStreetMap infrastructure later this year which will help in further developing such geo-functionality. Is this a blocker for the return of the nearby feature to the app? In splitting this thread and describing it as off topic, you've overlooked that my comments were in the context of - and in response to - your comment about change-aversion [tending] to correlate pretty strongly with impact on existing workflows and noticeable changes to user experience and behaviour. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Wikimedia Mexico. Report of Activities of June 2014
Dear community: Below you will find the report of activities of the month of June 2014 done by the volunteers of Wikimedia Mexico. Please don't hesitate to get in touch with us if you require extra information about this activities or only to make some suggestions. The report is also available on Spanish and English in our wiki: *https://mx.wikimedia.org/wiki/Informes/Junio_2014/ https://mx.wikimedia.org/wiki/Informes/Junio_2014/* (Spanish) *https://mx.wikimedia.org/wiki/Informes/Junio_2014/en https://mx.wikimedia.org/wiki/Informes/Junio_2014/en* (English) Kindly regards. On behalf our chapter. Carmen Alcázar (User:Wotancito) WMMX Secretary. ==Highlights== ===Edit-a-thon at Museo Soumaya=== On June 6th, we performed our first Edit-a-thon in Museo Soumaya, a private museographic institution belonging to Fundación Carlos Slim, at its Plaza Carso venue, previously planned jointly with the museum's curators about topics related to their collections. As the first activity, the Wikimedia México community attendees received a special backstage guided tour with the museum closed. At 10 a.m. we began the edition marathon and a workshop for beginners attending the event who do not have any previous experience in Wiki edition. The event was held at the lobby of the museum, a plain and blank area surrounded by master workshops as an exact replica of Michelangelo's Pietà and Rodin's Kiss, plus murals by Mexican masters Rufino Tamayo and Diego Rivera. The event generated awareness among the visitors of the museum, some of whom received explanations offered b the volunteers of the Mexican chapter about the activity we had been performing. Wikimedia Mexico's volunteers, jointly with the museum, created 9 new articles in Spanish Wikipedia and one in Wikivoyage. Rufino Tamayo's works such as Naturaleza muertaand El día y la noche, or Edgar Degas's Woman Bathing have now an article on the main Internet reference. This event was actively supported by the director of the museum, Alfonso Miranda, as well as by his research and outreach staff, who provided the information necessary to give depth to the writing and verifiability. Officialy the event ended at 3 pm, but some of the members of the chapter remained at the museum discussing and improving the contents written with the support of Soumaya staff until 10 pm. This event was part of the GLAM initiative between the Mexican chapter and Museo Soumaya. Images on Wikimedia Commons [1] Event on Spanish Wikipedia (with a list of edited articles) [2] Social media posts and impact around the event on Storify [3] ===First Spanish Republican Exile Edit-a-thon=== Francisco Franco's dictatorship and the Civil War in Spain forced hundreds of Spanish citizens to exile: they left their country as one of the aftermaths of the persecution period. Nearly 220 thousand supporters of the Second Republic left Spain to other countries such as Argentina and Mexico, who welcomed him differently. To mark the 75th anniversary of the arrival of Sinaia vessel to the Mexican port of Veracruz, three Wikimedia chapters (Wikimedia Argentina, Wikimedia Spain and Wikimedia Mexico) ran the First Spanish Republican Exile Edit-a-thon of Wikipedia, Wikimedia Commons and Wikisource about the historical facts, biographies and testimonials related to this process. The coordination of this event, performed under Iberocoop's initiative, meant that the work would be done at different times on June 16th. Articles were written in Spanish and Catalan. Several original texts and photographs of documents of those years were downloaded to both Wikisource and Commons either during the event or during the days following. The event was simultaneously held at Centro Cultural de España en México, in Mexico City, and at Casal de Catalunya in Buenos Aires, Argentina; editors from Spain participated from their home computers in the Spanish territory. Watch the video about the event in Mexico City. [4] Images and documents from Exile on Wikimedia Commons [5] Event on Spanish Wikipedia (with a list of edited articles) [6] ===Campus Party 2014=== This year Campus Party took place in Zapopan, Jalisco in the metropolitan area of Guadalajara, western Mexico. Wikimedia Mexico participated through our members Alan Lazalde, Omar Sandoval and Salvador Alcántar. During the event was diffused Wikimedia Mexico activities and sought new contacts within the technological environment. Also the team gave two talks, one about Wikipedia and other about Wikipedia Education Program in Mexico, but also was given last minute talks within the event. Near 300 stickers of Wikipedia and Wikimedia Mexico were distributed. Due to some acts of sexism and misogyny occurred during the event, the chapter members demonstrate his oppose against that kind of doings in technology events. The board of Wikimedia Mexico drafted and approved a special position on the situation, which was widely shared on social media. ===New GLAM friends on board===
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Sat, Jul 12, 2014 at 12:22 AM, Gergo Tisza gti...@wikimedia.org wrote: On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmal...@gmail.com wrote: That doesn't, however, help the concern that millions of users are pulling up the images without immediately seeing the license requirements and author information. To the contrary, Media Viewer displays the license, author and source as an always visible part of the image. On a typical file page, you have to scroll down to find any of this information; most users won't do that, if what they are looking for is the image, and that is available without scrolling. (It is well known in web usability http://www.nngroup.com/articles/scrolling-and-attention/ that relatively little attention is given to things above the fold; one of the main benefits of Media Viewer is that it brings the most important things above it.) Agree. The best practices for marking a work is to *make sure that the license information is clearly visible underneath (or otherwise next to) the image. [1] [2]* *1. **http://wiki.creativecommons.org/Marking_your_work_with_a_CC_license http://wiki.creativecommons.org/Marking_your_work_with_a_CC_license* *2. http://www.newmediarights.org/guide/how_to/creative_commons/best_practices_creative_commons_attributions http://www.newmediarights.org/guide/how_to/creative_commons/best_practices_creative_commons_attributions* *Unfortunately our file description page give more importance for subject description and bury the attribution parameters in a negligible location. As a result most reuses end up with an attribution, Credit:Wiki[m/p]edia. :(* *Jee* ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Fri, Jul 11, 2014 at 2:52 PM, Gergo Tisza gti...@wikimedia.org wrote: On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmal...@gmail.com wrote: That doesn't, however, help the concern that millions of users are pulling up the images without immediately seeing the license requirements and author information. To the contrary, Media Viewer displays the license, author and source as an always visible part of the image. On a typical file page, you have to scroll down to find any of this information; most users won't do that, if what they are looking for is the image, and that is available without scrolling. (It is well known in web usability http://www.nngroup.com/articles/scrolling-and-attention/ that relatively little attention is given to things above the fold; one of the main benefits of Media Viewer is that it brings the most important things above it.) Also, many people might not use file pages simply because they are so slow. A famous experiment by Google http://googleresearch.blogspot.com/2009/06/speed-matters.html showed that lowering loading speed by 200 ms resulted in 0.3% less interactions (on the English Wikipedia's scale, that would be about 20,000 thumbnail clicks a day). MediaViewer improves image loading time by a full second for the median user. George has made a useful contribution here, in that his points appear to be actually testable. Could the WMF or someone else look into user-testing how the MediaViewer (and variations on it) affects the average reader's perception and consciousness of the licensing information? Thanks, Pharos ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Proposal: List administration policy
For almost 2 years I was put under intense harassment on English Wikipedia by one the vilest groups that Wikipedia has seen--the EEML,[1] and one of the accusations that was often levelled against me is that I was an agent of the Russian government. And for 2 years the Community stood by and did absolutely nothing -- except for blocking me numerous times and eventually indefinitely topic banning me. In fact, the suggestion was even made by a long-standing member of the Community that an anonymous tip should be made naming me as a Russian spy.[2] Such accusations are never acceptable, and Trillium Corsage should be shown the door completely with their backdoor continued accusations which are made without a shred of proof. [1] https://en.wikipedia.org/wiki/WP:EEML [2] https://en.wikipedia.org/wiki/Wikipedia:Arbitration/Requests/Case/Eastern_European_mailing_list/Evidence/Russavia#Discussions_relating_to_stalking.2Fharrassing_myself_in_real_life On Sat, Jul 12, 2014 at 3:51 AM, Risker risker...@gmail.com wrote: Actually, Trillium Corsage, I'd say that's a reason for banning you again. It's a very serious allegation you're implying about a longstanding member of our community. Risker On 11 July 2014 14:24, Trillium Corsage trillium2...@yandex.com wrote: Hi Fae, I was banned from the list by Austin Hair. I had contributed in my view a lot of good and polite stuff that was reasonably reasoned, but he banned me on the basis of a 17-word parenthetical phrase regarding arbitrator Timotheus Canens. I said that I had read it claimed that he was connected to Chinese military intelligence. Is that a reason to ban me? I emailed him, and then repeat emailed him to talk to me about it. I was met by silence. I wasn't going to get upset about it, and didn't. I figure Austin just another type who got moderator privilege on a mailing list. It's not even worth it to criticize him, but I guess I'll notice he banned me within minutes, and he hasn't posted to the list anything since, and I don't recall him ever contributing a email of substantive opinion since I joined the list. I logged on here today with the aim of unsubscribing to the list, but I'll keep reading long enough to see if your below email asking for transparency on the list goes anywhere. Good luck. Trillium Corsage 11.07.2014, 11:28, Fæ fae...@gmail.com: Hi, I would like to propose that this list have a published process for post moderation, banning and appeals. Perhaps a page on meta would be a good way to propose and discuss a policy? I would be happy to kick off a draft. This list has a defined scope at https://lists.wikimedia.org/mailman/listinfo/wikimedia-l which explains who the 3 list admins are, but no more than that. There is no system of appeals, no expected time limits on bans or moderation, nor an explanation of the 30 posts per month behavioural norm that sometimes applies to this list. Neither is there any explanation of what is expected of list admins, such as whether there is an obligation to explain to someone who finds themselves subject to moderation or a ban, as to why this has happened and what they ought to do in order to become un-banned or un-moderated. I believe this would help list users better understand what is expected of them when they post here and it may give an opportunity to review the transparency of list administration, such as the option of publishing a list of active moderated accounts and possibly a list of indefinitely banned accounts where these were for behaviour on the list (as opposed to content-free spamming etc.) I see no down side to explaining policy as openly as possible. Thoughts? Fae -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae (P.S. I am active on the English Wikipedia where I have a GA on the go, see https://en.wikipedia.org/wiki/User:Fae. Sorry to disappoint, but reports of my retirement are premature.) ___ 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-requ...@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/guidelineswikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Re: [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Wednesday's quarterly review of the Foundation's Wikipedia Zero (Mobile Partnerships) team are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Wikipedia_Zero/July_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@wikimedia.org wrote: Hi folks, to increase accountability and create more opportunities for course corrections and resourcing adjustments as necessary, Sue's asked me and Howie Fung to set up a quarterly project evaluation process, starting with our highest priority initiatives. These are, according to Sue's narrowing focus recommendations which were approved by the Board [1]: - Visual Editor - Mobile (mobile contributions + Wikipedia Zero) - Editor Engagement (also known as the E2 and E3 teams) - Funds Dissemination Committe and expanded grant-making capacity I'm proposing the following initial schedule: January: - Editor Engagement Experiments February: - Visual Editor - Mobile (Contribs + Zero) March: - Editor Engagement Features (Echo, Flow projects) - Funds Dissemination Committee We’ll try doing this on the same day or adjacent to the monthly metrics meetings [2], since the team(s) will give a presentation on their recent progress, which will help set some context that would otherwise need to be covered in the quarterly review itself. This will also create open opportunities for feedback and questions. My goal is to do this in a manner where even though the quarterly review meetings themselves are internal, the outcomes are captured as meeting minutes and shared publicly, which is why I'm starting this discussion on a public list as well. I've created a wiki page here which we can use to discuss the concept further: https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
