Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
One problem is that the necessity to link to a working test environment does not allow to develop ideas with the community before they are implemented. 2013/4/9 Amir E. Aharoni amir.ahar...@mail.huji.ac.il 2013/4/9 Steven Walling steven.wall...@gmail.com: One system that I find a lot of potential value in is the Wikitech Ambassadors mailing list. I hope that mailing list grows and can be the place where we make announcements that should be communicated widely. Yes, that, but to make it really useful testing environments must be set up. Every email to that mailing list must have a tl;dr version that MUST have the following two things: 1. A two-line-max description of the feature that is going to be deployed. 2. A link to a working testing environment where the feature can be tested. It can be labs or something like test.wikipedia. Or a feature can be available using a preference which is off be default. Let people test - and make it easy. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
Those are very good points, both of them. Thanks. 2013/4/9 Matthew Flaschen mflasc...@wikimedia.org On 04/09/2013 12:18 PM, Denny Vrandečić wrote: I thought that in order to discuss these design decisions with the community before hand, telling them on their respective village pump is sufficient. Not so it seems. No single channel would find acceptance to communicate with the community. This, obviously means, that it is not actionable to communicate with the community. First of all, some people (including on English Wikipedia) are quite happy with the idea of deploying Wikidata Phase II. Those who are not seem to be arguing for a community-wide RFC before allowing deployment. It does not seem that they are arguing no one was notified. What about setting up a community selected body of representatives to discuss such issues beforehand? At first, it sounds like a good idea - but the issue is, it makes the process only more complicated without at all resolving the underlying issues. Does anyone really think that such a body would stop the criticism before or after the deployment of the change in question? Yeah, right. Doesn't change a thing. Yeah, I do not think this is a good idea. When something does need a community decision (not saying everything does), I don't think some new special council will help anything. That would basically introduce indirect democracy in place of direct consensus. Community-wide RFCs are not always smooth, but they do usually work. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
On Apr 15, 2013 5:06 PM, Denny Vrandečić denny.vrande...@wikimedia.de wrote: One problem is that the necessity to link to a working test environment does not allow to develop ideas with the community before they are implemented. Nobody is asking of you to have a testable with every idea you bounce of the mailinglist, but this does ask for a testable setup at some point before implementing. I understand this is a pain, because it runs the risk of rejection after you put in enough effort to make a prototype. But better a community cry out at a proto than at a full implementation ready to merge into core. In other words, all discussion is welcome, with or without proto, but don't expect final community buy in before we have been able to toy around with it. 2013/4/9 Amir E. Aharoni amir.ahar...@mail.huji.ac.il 2013/4/9 Steven Walling steven.wall...@gmail.com: One system that I find a lot of potential value in is the Wikitech Ambassadors mailing list. I hope that mailing list grows and can be the place where we make announcements that should be communicated widely. Yes, that, but to make it really useful testing environments must be set up. Every email to that mailing list must have a tl;dr version that MUST have the following two things: 1. A two-line-max description of the feature that is going to be deployed. 2. A link to a working testing environment where the feature can be tested. It can be labs or something like test.wikipedia. Or a feature can be available using a preference which is off be default. Let people test - and make it easy. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
On Mon, Apr 15, 2013 at 1:32 PM, Martijn Hoekstra martijnhoeks...@gmail.com wrote: In other words, all discussion is welcome, with or without proto, but don't expect final community buy in before we have been able to toy around with it. And even then, some people will ignore the prototype and then complain anyway when it is due to be enabled. -- Brad Jorsch Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
On Mon, Apr 15, 2013 at 8:06 PM, Brad Jorsch bjor...@wikimedia.org wrote: On Mon, Apr 15, 2013 at 1:32 PM, Martijn Hoekstra martijnhoeks...@gmail.com wrote: In other words, all discussion is welcome, with or without proto, but don't expect final community buy in before we have been able to toy around with it. And even then, some people will ignore the prototype and then complain anyway when it is due to be enabled. Not being a native speaker, I'm not sure if that last email sounded unduly harsh. As a (possibly unneeded) clarification, I meant to indicate that a wikis community in general (and en-wiki in particular) may not, and will not in some cases, gladly welcome a change without a chance to look at it and take it around the block (or actually as Brad indicates, sometimes even with that chance), not take a position on the desirability of this situation: I can understand both perspectives quite well. -- Brad Jorsch Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Pushing Technical changes to Wikimedia projects
Technical changes on the Wikimedia projects can be hairy. We are currently having a discussion about the Wikidata deployment to the Wikipedias, and there have been many examples in the past of deployments that raised discussions. One of my statements in this discussion is that the a priori discussion of such features is highly undemocratic. What I mean with that is that design and deployment decisions are often made by a very small group, which are in the best case a part of the affected community, but, in many cases, even external to the affected community. So the decisions are made by a group that does not represent or is constituted by the community - which I mean with undemocratic. This has repeatedly raised criticism. And I think that criticism is often unfair. Additionally, it is usually true (which makes is not anymore fair, though). I thought that in order to discuss these design decisions with the community before hand, telling them on their respective village pump is sufficient. Not so it seems. No single channel would find acceptance to communicate with the community. This, obviously means, that it is not actionable to communicate with the community. What about setting up a community selected body of representatives to discuss such issues beforehand? At first, it sounds like a good idea - but the issue is, it makes the process only more complicated without at all resolving the underlying issues. Does anyone really think that such a body would stop the criticism before or after the deployment of the change in question? Yeah, right. Doesn't change a thing. So, what do I want to achieve with this Mail? Merely to ask some community members to be a bit more constructive in their comments. Claiming that the product managers and designers have no idea of the Wikimedia communities and the use of wikis is often neither help- nor truthful. What would be even better would be to come up with processes or mechanisms to avoid these issues in the future. I would be very glad if the people who are often critically accompanying such changes would help in building effective channels for their discussion. Any thoughts? -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
What kind of changes are we talking about here? What exactly falls under the category of design decisions? Because, for example, my Gerrit change that converts Special:Userlogin into a FormSpecialPage is a design change (in the software sense of the word), but the change based on it to add the VForm version of the login page is also a design change (in the graphical sense of the word). I'm very hesitant to support some sort of complicated approval process for submitting changes to the core, primarily because it already takes an extraordinary amount of time to get changes submitted. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
On Tuesday, April 9, 2013, Denny Vrandečić wrote: Technical changes on the Wikimedia projects can be hairy. We are currently having a discussion about the Wikidata deployment to the Wikipedias, and there have been many examples in the past of deployments that raised discussions. One of my statements in this discussion is that the a priori discussion of such features is highly undemocratic. What I mean with that is that design and deployment decisions are often made by a very small group, which are in the best case a part of the affected community, but, in many cases, even external to the affected community. So the decisions are made by a group that does not represent or is constituted by the community - which I mean with undemocratic. This has repeatedly raised criticism. And I think that criticism is often unfair. Additionally, it is usually true (which makes is not anymore fair, though). I thought that in order to discuss these design decisions with the community before hand, telling them on their respective village pump is sufficient. Not so it seems. No single channel would find acceptance to communicate with the community. This, obviously means, that it is not actionable to communicate with the community. What about setting up a community selected body of representatives to discuss such issues beforehand? At first, it sounds like a good idea - but the issue is, it makes the process only more complicated without at all resolving the underlying issues. Does anyone really think that such a body would stop the criticism before or after the deployment of the change in question? Yeah, right. Doesn't change a thing. So, what do I want to achieve with this Mail? Merely to ask some community members to be a bit more constructive in their comments. Claiming that the product managers and designers have no idea of the Wikimedia communities and the use of wikis is often neither help- nor truthful. What would be even better would be to come up with processes or mechanisms to avoid these issues in the future. I would be very glad if the people who are often critically accompanying such changes would help in building effective channels for their discussion. Any thoughts? One system that I find a lot of potential value in is the Wikitech Ambassadors mailing list. I hope that mailing list grows and can be the place where we make announcements that should be communicated widely. For Wikidata in particular, one tool I think you guys haven't yet used and should consider for after Phase II is launched on enwiki is a watchlist notice. This is very effective for reaching active editors about a new feature. We've used it for Editor Engagement Experiments and for mobile features announcements. Another tool that we should consider in the near future is the upcoming notifications system for Web and email. This is potentially a powerful system. Having things like the Kurier (sp?) and Signpost delivered via notification will only make them more effective. And we might consider doing occasional (e.g. quarterly) email announcements about major features like Wikidata and VisualEditor. -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Pushing Technical changes to Wikimedia projects
On Tuesday, April 9, 2013, Tyler Romeo wrote: What kind of changes are we talking about here? What exactly falls under the category of design decisions? Because, for example, my Gerrit change that converts Special:Userlogin into a FormSpecialPage is a design change (in the software sense of the word), but the change based on it to add the VForm version of the login page is also a design change (in the graphical sense of the word). I'm very hesitant to support some sort of complicated approval process for submitting changes to the core, primarily because it already takes an extraordinary amount of time to get changes submitted. *-- * *Tyler Romeo* I think Denny is talking less about creating new approvals and review processes to gate design changes, and more about how to communicate about changes effectively. Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
2013/4/9 Steven Walling steven.wall...@gmail.com: One system that I find a lot of potential value in is the Wikitech Ambassadors mailing list. I hope that mailing list grows and can be the place where we make announcements that should be communicated widely. Yes, that, but to make it really useful testing environments must be set up. Every email to that mailing list must have a tl;dr version that MUST have the following two things: 1. A two-line-max description of the feature that is going to be deployed. 2. A link to a working testing environment where the feature can be tested. It can be labs or something like test.wikipedia. Or a feature can be available using a preference which is off be default. Let people test - and make it easy. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
On 04/09/2013 12:18 PM, Denny Vrandečić wrote: I thought that in order to discuss these design decisions with the community before hand, telling them on their respective village pump is sufficient. Not so it seems. No single channel would find acceptance to communicate with the community. This, obviously means, that it is not actionable to communicate with the community. First of all, some people (including on English Wikipedia) are quite happy with the idea of deploying Wikidata Phase II. Those who are not seem to be arguing for a community-wide RFC before allowing deployment. It does not seem that they are arguing no one was notified. What about setting up a community selected body of representatives to discuss such issues beforehand? At first, it sounds like a good idea - but the issue is, it makes the process only more complicated without at all resolving the underlying issues. Does anyone really think that such a body would stop the criticism before or after the deployment of the change in question? Yeah, right. Doesn't change a thing. Yeah, I do not think this is a good idea. When something does need a community decision (not saying everything does), I don't think some new special council will help anything. That would basically introduce indirect democracy in place of direct consensus. Community-wide RFCs are not always smooth, but they do usually work. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
On Tue, Apr 9, 2013 at 9:48 AM, Steven Walling steven.wall...@gmail.comwrote: On Tuesday, April 9, 2013, Denny Vrandečić wrote: Technical changes on the Wikimedia projects can be hairy. We are currently having a discussion about the Wikidata deployment to the Wikipedias, and there have been many examples in the past of deployments that raised discussions. One of my statements in this discussion is that the a priori discussion of such features is highly undemocratic. What I mean with that is that design and deployment decisions are often made by a very small group, which are in the best case a part of the affected community, but, in many cases, even external to the affected community. So the decisions are made by a group that does not represent or is constituted by the community - which I mean with undemocratic. This has repeatedly raised criticism. And I think that criticism is often unfair. Additionally, it is usually true (which makes is not anymore fair, though). I thought that in order to discuss these design decisions with the community before hand, telling them on their respective village pump is sufficient. Not so it seems. No single channel would find acceptance to communicate with the community. This, obviously means, that it is not actionable to communicate with the community. What about setting up a community selected body of representatives to discuss such issues beforehand? At first, it sounds like a good idea - but the issue is, it makes the process only more complicated without at all resolving the underlying issues. Does anyone really think that such a body would stop the criticism before or after the deployment of the change in question? Yeah, right. Doesn't change a thing. So, what do I want to achieve with this Mail? Merely to ask some community members to be a bit more constructive in their comments. Claiming that the product managers and designers have no idea of the Wikimedia communities and the use of wikis is often neither help- nor truthful. What would be even better would be to come up with processes or mechanisms to avoid these issues in the future. I would be very glad if the people who are often critically accompanying such changes would help in building effective channels for their discussion. Any thoughts? One system that I find a lot of potential value in is the Wikitech Ambassadors mailing list. I hope that mailing list grows and can be the place where we make announcements that should be communicated widely. For Wikidata in particular, one tool I think you guys haven't yet used and should consider for after Phase II is launched on enwiki is a watchlist notice. This is very effective for reaching active editors about a new feature. We've used it for Editor Engagement Experiments and for mobile features announcements. I agree, a watchlist notice can be a good option in such cases, when only one wiki or a limited number need to be notified. BTW, I gave an overview of this and other existing on-wiki broadcasting channels as part of this Wikimania talk: https://wikimania2012.wikimedia.org/wiki/File:Wikimania_2012_-_Movement_broadcasting_mechanisms.pdf . (The TranslationNotifications extension is a newer - specialized - example that wasn't mentioned there yet.) Basically, while mailing lists and the central coordination wikis -Meta, Mediawiki.org - are good and important, it has become very clear over the years that many editors are reluctant to leave their home wiki and prefer to receive news and notifications there. So communications-wise the WMF projects present themselves as a huge landscape ( https://wikimania2012.wikimedia.org/w/index.php?title=File:Wikimania_2012_-_Movement_broadcasting_mechanisms.pdfpage=3 ) of islands that can only be reached by sophisticated, expensive aircraft (CentralNotice) and shaky boats (Global message delivery) ;) Another tool that we should consider in the near future is the upcoming notifications system for Web and email. This is potentially a powerful system. Having things like the Kurier (sp?) and Signpost delivered via notification will only make them more effective. Yes, this has huge potential to improve the current situation. I know that such a functionality has been on the mind of the Echo (Notifications) and Flow teams for quite a while, but unfortunately it seems they had to deprioritize it at least for the coming months. See also https://bugzilla.wikimedia.org/show_bug.cgi?id=35306 https://bugzilla.wikimedia.org/show_bug.cgi?id=43840 And we might consider doing occasional (e.g. quarterly) email announcements about major features like Wikidata and VisualEditor. -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
On 04/09/2013 12:57 PM, Amir E. Aharoni wrote: 2013/4/9 Steven Walling steven.wall...@gmail.com: One system that I find a lot of potential value in is the Wikitech Ambassadors mailing list. I hope that mailing list grows and can be the place where we make announcements that should be communicated widely. I'd like to second this. More info: https://meta.wikimedia.org/wiki/Tech/Ambassadors Yes, that, but to make it really useful testing environments must be set up. Every email to that mailing list must have a tl;dr version that MUST have the following two things: 1. A two-line-max description of the feature that is going to be deployed. 2. A link to a working testing environment where the feature can be tested. It can be labs or something like test.wikipedia. Or a feature can be available using a preference which is off be default. Let people test - and make it easy. I agree that emails to wikitech-ambassadors should definitely have a short, plain-English how this affects you summary. A link to a place to test also sounds ideal. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
