User talk:Leucosticte/WikiProject Interwiki Integration

Discussion

See:

• en:Wikipedia:Village pump (idea lab)#Why does Wikimedia need more than one MediaWiki installation? --Timeshifter 02:51, 29 May 2010 (UTC)

Where does it end

I guess interwiki integration could theoretically go on forever, unless at some point a centralized, worldwide database is created to serve all the wikis. We already have methods for integrating namespaces, which are divisions within a wiki. We have also created some interwiki integration for wikis on the same wiki farm. Now we're going to create ways for wiki farms to integrate with one another. But then, what about integration of different groups of wiki farms? (E.g., how will the wiki farm group created by the integration of your and my wiki farm integrate with other wiki farm groups?) And then integration of different groups of groups of wiki farms? And so on. Tisane 14:20, 1 June 2010 (UTC)

Indeed, you need to keep a sense of perspective. Where it "ends" is when technical issues become social ones. As pointed out in the discussion on enwiki, merging, say, enwiki and enwiktionary is not a technical question, it's a unification of two communities, policies, and ethea which is arguably not desirable. It's easy to sit in enwiki, the largest collaborative project in human history, and make grand plans to merge the entire world into it; but the question of whether that's realistic goes far beyond mere technical feasibility.

My suggestion would be to not bite off more than you can chew, and to avoid the social challenges when there is still a huge amount of technical work to be done. There is a huge amount that can be done to improve the technical implementation of the social structure we have already, without worrying about making grander changes still. Happy‑melon 14:44, 1 June 2010 (UTC)

I'm not sure that there are any truly social problems in the wikisphere. Ultimately, technology can solve everything. E.g., vandalism might be viewed as a social problem, if one views it as maladjusted, evil, or whatever to devote large amounts of time to, say, engaging in willy-on-wheels-type behavior. And people devote a lot of time to talking about vandalism, setting up disciplinary processes, etc. But vandalism has a technical solution if, say, ClueBot can detect and stop it from happening and repair the damage. I pointed out too on the listserv that software like Extension:ImageFilter, if improved, could help resolve some debates on morality. Likewise, the inclusionist/deletionist debate, I suspect, has a technical solution, and the key to that solution, as I envision it, will partly be interwiki integration. Wikimedia may not have much interest in resolving that age-old conflict in a way that will satisfy the inclusionists, but I think some of the software used to implement that solution will also benefit Wikimedia. And once the inclusionist/deletionist issue is solved, then I think 90% of what causes disputes on Wikimedia will have been dealt with. Tisane 15:28, 1 June 2010 (UTC)

I, and I suspect most of the other MW devs, very much disagree with that technology-is-the-solution-to-all-problems belief. Technology cannot defeat human ingenuity without also defeating itself: yes, we can build better and more effective antivandal bots and scripts, but as long as the systems we build are less intelligent than the humans they are countering (and are not self-defeating no-one-can-edit-therefore-no-one-can-vandalise 'solutions'), the humans can and will circumvent them. That determination to continue in an arms race which has no reward other than 'lulz', is an entirely social problem, and one that technology can never solve. Equally, the threads of pride and humility, generosity and arrogance, authority and respect, ingenuity and inertia, that permeate all our communities, are social phenomena: when those intangible concepts oppose or block technical changes which are objectively 'for the better', such as the recent skin change; that is unquestionably a social question, and one that actively rejects any technical "solution". For as long as wikis are unable to write themselves, they must have communities of humans to write them; and humans are social animals with social problems. To think otherwise will lead you to write code and features which are not suitable for the jobs you intend them for. Happy‑melon 18:27, 1 June 2010 (UTC)

I hope that eventually, the wikis do write themselves. I like working with people, and I find them to be at times amusing, engaging, interesting, helpful, etc. but they are also frustrating to deal with at times, and ultimately much work has to be done mostly alone because others don't share the same vision or priorities. I am also amazed sometimes at how the people who make up the rough consensus will not only be wrong but be very resistant to being corrected, even when pretty good arguments and evidence are presented. That occurs both in Wikimedia and in our larger society.

As for Vector and the rest of the UsabilityInitiative, I think perhaps it wasn't marketed well (marketing being a mix of price, product, place and promotion). The devs basically said "This is a really awesome change and more good enhancements will come from it," but it may not have been evident to the average user what the big deal was, apart from items being moved around. Maybe they'll change their minds after some killer apps appear.

In my experience, pride, arrogance, disrespect, etc. don't seem to be big problems; I think users' hearts are in the right place, but they tend to be pretty conservative and want to err on the side of not making changes that could have harmful results, even if it means forgoing a lot of changes that probably would have been, on balance, beneficial. There is also somewhat of a disconnect among users who carry out different tasks; e.g. TimeShifter evidently runs into a lot of troublesome sockmasters and therefore places a high priority on stopping them, whereas I don't run into them all that much in my areas of focus, so I care more about making sure we don't do anything to deter new users for joining. Wikipedia is such a big project that people have trouble seeing the big picture sometimes and accurately judging what will be in the overall best interest of the project as a whole.

As for writing code/features that aren't appropriate, arguably a lot of our extensions would fall into that category. E.g., Extension:EmergencyDesysop might not work too well in practice, due to the human factor. PureWikiDeletion isn't of much use either unless wikis are willing to use it. But whatever. Like Nupedia, a lot of ideas are not an ideal solution in and of themselves, but they can help lead to a workable solution. Tisane 22:17, 1 June 2010 (UTC)

You've taken all the words right out of my mouth. Vector being badly marketed is a social problem to which there are only social solutions; equally the conservatism to the point of complete inertia; equally people not seeing 'the big picture'. None of these problems, which often stand in the way of technical advancement, can be solved by more code or another extension or an extra database table. You absolutely can't ignore that human factor, because it not only determines whether or not a technical change will be accepted, it determines whether the change should be implemented. Your example of Extension:EmergencyDesysop is a perfect one: a clever piece of code which would work fine in an alternate universe not inhabited by the drama-mongering communities for whom it was written. Whether or not a community such as enwiki thought such an extension was a good idea, there is absolutely no way it should be implemented; it is simply not usable by communities with the human traits found in the larger WMF projects. The work that went into that extension, if it was aimed at WMF wikis, was wasted. A codebase that requires the social merging of wiki projects is similarly wasted; that's a social mountain that just doesn't need to be climbed to achieve the technical goals that are desired. Technical changes which have attached social strings, such as UI, FlaggedRevs or LiquidThreads, require huge amounts of organisation, planning and social lobbying, and as we've seen, are still painful to implement. MediaWiki has literally thousands of technical loose ends which can be tied up to deliver a better editing experience without touching any social third rails. Happy‑melon 23:12, 1 June 2010 (UTC)

Actually, I find that LiquidThreads also has some technical issues. The overall concept is good, but for instance, I don't like the fact that it creates a separate page, showing up as a separate item in search results, for each comment. I haven't devoted a lot of thought yet to how forums could be done better, but I suppose I should, because it'll probably be hard to change once it's installed everywhere.

I have a grand vision (which is still evolving) for sweeping technical and other changes, but I know Wikimedia won't implement them until they are tested and shown to work well elsewhere; and possibly even then they won't implement them. Therefore, I want to set up my own production-level wiki farm to do what Wikimedia refuses to do. I usually don't discuss that very openly because people's attitude toward such things is "If that's your plan, then go away," but at least MediaWiki.org is pretty open-minded and generous in helping support/facilitate non-Wikimedia endeavors in various ways (e.g. facilitating collaboration on extensions that may never be used on Wikimedia).

For instance, I want to set up branching of articles, similar to what SVN does, because it fits into my larger scheme. Most of the features I envision are kinda tied together; viewed separately, people might easily say (and they do say) "that's a terrible/useless idea," but there's a bigger scheme they fit into, which I'll do a writeup of. Extension:FrontBackMatterForcedWikilinks is probably a good example; it is presently pretty useless, but probably rather important to the wiki farm I'm going to set up. To take another example, adding code to a website to allow anyone to edit it doesn't make sense by itself, but it is workable and even desirable when accompanied by other features, such as Special:Watchlist and Special:RecentChanges.

I suspect that eventually, I'll exhaust Wikimedia's generosity, at which point, I'll just have to offer some money in exchange for continued use of their resources, which they may or may not accept. I find it a bit disturbing that they quit selling the m:Wikimedia update feed service. In my view, that was a step backward for openness and viability of mirror/fork/supplements such as what I want to create. Tisane 00:00, 2 June 2010 (UTC)

Forge Wiki aspects

FusionForge (and our company’s instance thereof, Evolvis, which adds another layer of confusion due to running several forges, some private some semi-open but separated from each other, one public) offer one MediaWiki instance per “group” (forge project), which are separated at the moment, using PostgreSQL schemata (although, in Evolvis, the interwiki table is shared). However, as system administrator, I sort of would like to have one of the Wikis’ (e.g. that of the “Site Admin” group, which always exists – membership in it means global administration permissions) content being accessible everywhere, especially in the context of Semantic Mediawiki (nothing done in that regard yet), but also considering things like templates. If things could even go cross-forge, even more welcome. Mirabilos 22:18, 7 October 2010 (UTC)