On Mon, Apr 8, 2013 at 10:59 AM, Risker <risker...@gmail.com> wrote: > On 8 April 2013 12:51, Brad Jorsch <bjor...@wikimedia.org> wrote: > > > On Mon, Apr 8, 2013 at 12:16 PM, Risker <risker...@gmail.com> wrote: > > > > > > I do not think it is particularly obvious outside of our project the > way > > > that Wikidata is being "weaponized" as the reason for attempting to > force > > > changes in local consensus about infoboxes (their existence and > content) > > > with respect to specific article categories or even individual > articles. > > > > It's not obvious within the project either, at least for someone like > > me who hasn't been following the endless arguments over whether some > > WikiProject should be able to decide not to use infoboxes on "their" > > articles and whether they're ganging up to prevent any local consensus > > to use infoboxes on "their" articles, etc, etc, etc. > > > > Personally, I don't consider that people making spurious arguments > > based on the existence of wikidata is a problem with the planned > > wikidata phase 2 deployment. > > > > > Why do you think those arguments are spurious? Just because you don't > agree with them doesn't make them spurious. Those articles belong a lot > more to the editors of each of the Wikipedias than they do to Wikidata, or > Wikimedia, that's for certain. >
Not agreeing with the arguments of some editors *also* doesn't mean the entire engineering and operators department is "doing it wrong", or that the Wikidata project (which is not developed by WMF, incidentally, and is having its own interesting discussions *among its own community* as we speak) somehow is not capable of also debating these questions. I do not agree with your arguments, Risker. I think Wikidata is great and I am happy it has been deployed (or will be soon). I think it will enable lots and lots of super cool things in the years to come, and having over the years lived through the deployments of commons, categories, new skins and who knows what else I am also confident, along with Denny, that we will figure it out in the wild as we go. That viewpoint doesn't make me a bad Wikipedian, and it doesn't mean I'm not willing to hear you and others who disagree out (and I'm perfectly willing to learn about the infobox debates, which are actually new to me -- somehow in 10 years of editing I've managed to avoid this hotbed of disagreement). But do please bear in mind that in your messages you are telling *the entire* technical list, including all the paid development staff and the longtime technical volunteers, which includes pretty much everyone who has written MediaWiki over the years, that they don't know how wiki development works. In my opinion that's pretty patronizing, and is not helping your argument -- which, as far as I can tell, is that Wikidata phase II shouldn't be enabled on en:wp except after a community-wide RFC, correct? As far as that goes, since you are so strongly arguing for the autonomy of en:wp, I think the ball's in the en:wp court; an en:wp editor should be the one to organize an RFC. If the results skew strongly to one side or another, the WMF has listened to such things in the past. Personally I don't see the need for an RFC at this point in time, but I certainly don't begrudge anyone else the right to organize one, and I will happily vote accordingly. -- phoebe -- * I use this address for lists; send personal messages to phoebe.ayers <at> gmail.com * On Mon, Apr 8, 2013 at 10:59 AM, Risker <risker...@gmail.com> wrote: > On 8 April 2013 12:51, Brad Jorsch <bjor...@wikimedia.org> wrote: > > > On Mon, Apr 8, 2013 at 12:16 PM, Risker <risker...@gmail.com> wrote: > > > > > > I do not think it is particularly obvious outside of our project the > way > > > that Wikidata is being "weaponized" as the reason for attempting to > force > > > changes in local consensus about infoboxes (their existence and > content) > > > with respect to specific article categories or even individual > articles. > > > > It's not obvious within the project either, at least for someone like > > me who hasn't been following the endless arguments over whether some > > WikiProject should be able to decide not to use infoboxes on "their" > > articles and whether they're ganging up to prevent any local consensus > > to use infoboxes on "their" articles, etc, etc, etc. > > > > Personally, I don't consider that people making spurious arguments > > based on the existence of wikidata is a problem with the planned > > wikidata phase 2 deployment. > > > > > Why do you think those arguments are spurious? Just because you don't > agree with them doesn't make them spurious. Those articles belong a lot > more to the editors of each of the Wikipedias than they do to Wikidata, or > Wikimedia, that's for certain. > > It's disturbing that even at the same time as the engineering and > operations departments are working so hard to professionalize their work, > to bring themselves up to industry standards, to properly staff themselves > with people who understand not just the technical side, but also the > content side - that there remains this cowboy attitude toward applying > poorly developed software onto huge sites knowing full well that the > software create significant community disruption. This isn't a little > backwater website anymore, and it should never be the subject of a major > test without the active engagement of those who are going to be the test > subjects. > > Wiki design 101 is that nobody gets sent to another page/website/etc to > edit content on the Wikipedia. (Even clicking on an image that is held on > Commons takes people to a Wikipedia page for the image, and then gives them > the choice to go to Commons.) This software is not ready for deployment; > everyone here knows it. This is now just pride taking the place of common > sense. (And no, David, it's not bikeshedding.) > > Figure out why the content itself is being affected, instead of creating a > new namespace that will hold all this data: wikidata, authority control > data, H-cards, V-cards, and all the other miscellaneous stuff that has been > applied to articles. > > This is not a technical problem to be solved. It is at its core a > philosophical matter to be grappled with, project by project. > > Learn some lessons from the folks down the hall in Fundraising - who have > figured out how to fully fund all of these projects with the minimal amount > of disruption to the content and the editorial process. Figure out how to > do that, and you'll have a winner. > > Risker/Anne > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- * I use this address for lists; send personal messages to phoebe.ayers <at> gmail.com * _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
