Wikivoyage talk:Technical infrastructure policy

Purpose

Per discussion in the travellers' pub and suggestion from (WT-en) Ryan, this is a stab at making a technical infrastructure policy. The key things to note: new development plans of all type are going to go on Project:Feature requests. Also, new features that have a significant impact on the way the site works will be put up for community review at http://wikivoyage.org/review/ (not live yet).

Comments, questions, revisions requested. --(WT-en) Evan 05:15, 9 June 2006 (EDT)

• Thank you for writing this policy page. Hopefully, this will curb some of the animosity that has become prevalent throughout the community at large. I already added a link to this page on Project:Help under the Community section. I thought it belonged there, because of the "Is this still a community?" discussion, however, it probably could be placed somewhere else. - (WT-en) Andrew Haggard (Sapphire) 05:21, 9 June 2006 (EDT)

Process

Hi Evan. Thanks for starting this - it's a good start, although it would be nice to have a few more specifics. For example, could the "Process" section be broken down a bit more to make it very explicit what and how things are done? My suggestion would be three sub-sections:

• Hardware Upgrades. Note that Internet Brands owns the hardware and may make hardware changes without notice (unless IB / Evan plan is to provide notice).
• Software Upgrades & Bugfixes. Note that bugs reported on Project:Bug reports and upgrades to the MediaWiki software may be done without notice (although it would be good if some notice & status was provided for bigger issues). Note that bugs for all language versions should be reported on Project:Bug reports.
• Feature Requests. Note that all new feature requests (including those for non-English) will be queued on Project:Feature requests, and at least 24 hours will be provided for discussion prior to implementation (longer would be better, but it's up to Evan I guess). Note that once Evan / IB has agreed to implementt a feature then it will be implemented unless there is a consensus NOT to implement, and that Evan / IB has discretion over what features will be worked on. Note that IB / Evan will try to provide a status for new features (eg. "Low priority", "Will not implement", "Implementation planned for day/month/whatever") whenever possible.

The goal for this policy is to make it clear what the community's involvement in infrastructure changes will be, so explicitly saying that Project:Feature requests is the central point for feature discussion, that (at least) 24 hours notice will be provided for all feature discussion, and that features will be implemented unless there is a consensus NOT to implement would be a good thing. Also noting that Project:Feature requests and Project:Bug reports are the central points of discussion even for non-English (they are, right?) would be good. Thoughts? -- (WT-en) Ryan 13:02, 9 June 2006 (EDT)

I have some positives and negatives. I typically give about 2-3 days of notice before any changes (software upgrades or hardware changes) that actually cause downtime. Typical exceptions are emergency upgrades for, for example, security issues.

I agree that it's probably a good idea to re-emphasize that FR and BR are the places to look for technology plans for all language versions.

I'm not excited with the 24-hour limit. Is there really a problem with technical work coming too fast on Wikivoyage? I don't think so. If it's a question of providing optional tools that don't affect most of Wikivoyage (example: listings tags, related articles, docents, etc.) then I'd rather do iterative development than wait for everyone to decide what they think it might look like. Mostly, I'm not excited about working around legalistic restrictions. How about we just say, "For important changes, we'll try to give people a chance to comment?" If it gets to be a problem in the future, we can set some minimum time limits.

Finally, no, we're not going to implement every feature request that doesn't have consensus against it. Some requests are just going to be too resource-hungry (in developer time, run time, memory, hardware, whatever), or not focused on our goals. Other are going to be good ideas that are low priority. --(WT-en) Evan 19:11, 14 June 2006 (EDT)

Hi Evan. To be clear, the suggestions above were meant to help specify what the community's involvement with technical decisions will be. The current "policy" doesn't specifically state that the community has input into feature requests and such, and how you / IB will implement technical changes. Specifically saying that IB has control over the hardware and software and can change it without notice makes it very clear that the community should not expect to be consulted for those sorts of changes. Similarly with bug fixes, if you implement a bugfix and someone later complains, it's much easier to just be able to say "this was on Project:Bug reports and according to the Project:Technical infrastructure policy bugs get fixed without the need to notify everyone. If the policy includes verbage that downtimes are usually preceded by 2-3 days of notice, that would be even better.

That then leaves Project:Feature requests, which is most likely where the community would like to have input. The "24 hours of notice before feature implementation" proposal was merely meant to ensure that there is always a time for the community to comment before changes are made; it's up to you, but it would be nice to know what changes are coming and to be able to comment on anything that seems potentially evil. The TOC change was implemented without anyone expecting it, and the surprise and lack of time to comment is (I think) what upset most people. Most changes are probably no-brainers, but it would still be nice to know what's in the pipeline.

Your comment that "no, we're not going to implement every feature request that doesn't have consensus against it" is actually not what I meant - the proposal was that once you / IB say a feature is coming, it will be implemented unless there is a clear consensus of people saying not to do it. You / IB obviously allocate the resources of who is going to work on what features at what times, so the idea is that you can implement whatever you want, whenever you want to UNLESS the community is clearly against it. Again, putting this in writing would simply be a way to make it clear how things happen, and would avoid situations in the future where some community members feel like a change was not made in the spirit of community.

It's possible I'm the only one who would like to see these issues clarified, but it would be reassuring to have it specifically written out how the community will be involved on these issues. -- (WT-en) Ryan 20:22, 14 June 2006 (EDT)

OK, I think I understand better. I divided out the sections a little differently, and hopefully this meets the needs you're pointing out. Question: doesn't having a review site meet the needs that you're trying to get at with a 24-hour delay? --(WT-en) Evan 17:31, 17 June 2006 (EDT)

The changes look good and address my concerns. The sole reason I suggested the "24 hour" thing was just as kind of a security blanket to ensure that something won't be done on the review site without anyone noticing and then be pushed to the main site, but I'm fine with leaving that verbage out. Thanks for making these changes. -- (WT-en) Ryan 17:54, 17 June 2006 (EDT)

No problems. Thanks a lot for this great idea; I think it's really useful to have. I've been thinking for such a long time that we had an implicit tech policy like practically every other community Web site, not to mention wiki sites like Wikimedia, Wikia, etc. I'm glad we're now doing even better than that. --(WT-en) Evan 17:59, 17 June 2006 (EDT)

Review site

I've got a review site up at http://wikivoyage.org/review/ . It seems to be working OK, but some of the RDF-dependent features like docents and related pages don't work yet (they have some hardcoded URL prefixes in the related Template: articles). I have a couple of features I want to test out, not least the right-hand-side ToC. --(WT-en) Evan 11:59, 29 June 2006 (EDT)

Moving technical discussions to shared:

It's come up a couple of times before, but: some users on non-English Wikivoyage sites resent having to post their requests on en:. I wonder: would there be a problem in moving Feature Requests and Bug Reports to shared:, and making technical announcements on shared:? --(WT-en) Evan 11:48, 2 July 2006 (EDT)

Could the recent changes page for each language version be updated somehow to include changes to shared? That would make it vastly easier for each language to see what discussions are going on, what new images are available, etc. I'm guessing that the MediaWiki software might be unable to do this, but if you can think of anything... -- (WT-en) Ryan 12:14, 2 July 2006 (EDT)

Jeez, that's a great idea! I've thought about doing it with merged RSS feeds for various languages (see Project:Feature requests#Create a merged Recentchanges feed for all or some language versions but I think that the mainline case is to include shared: changes into each language version. --(WT-en) Evan 12:45, 2 July 2006 (EDT)

The proposal is on en:Project talk:Technical infrastructure policy and en:Project talk:Language version policy. It'd be especially great to get feedback from people who use shared: a lot. --(WT-en) Evan 13:17, 6 July 2006 (EDT)

I'm a bit sceptical of the move, because too few people use Shared. If the point is to include people in discussion I think EN makes the most sense because there are more users on EN and as language versions are a spin off of EN people will naturally gravitate toward EN. I understand Hans' proposal, but it will actually be counter productive. No one in the EN community is so anti- other perspectives that we would automatically dismiss any view points DE, PL, PT, ES, FR, NL, IT, SV, and JA users provide on an EN policy technical infrastructure page. -- (WT-en) Sapphire 11:04, 7 July 2006 (EDT)

I think that there are a couple of problems. First, there's just the perception of fairness. Why should all the discussion about things that affect all Wikivoyagers only be on en:? Why not on pl: instead? Or maybe spreading it around: bug reports on sv:, new language expeditions on es:, go-between reports on pt:. The answer, as you point out, is historical -- we've just always done it this way. But someone starting to use Wikivoyage today doesn't see that; they see one language version with all the major discussion happening, and a bunch of other ones that don't get the same.

Second, someone from fr: making a comment on en: feels like an outsider, not part of the discussion. It's easy to dismiss this feeling if you're an English speaker, but I think it's real.

Third, it's not clear what parts of en: affect all Wikivoyagers and what parts affect only en:. By moving discussions that affect all users to shared:, we'd have a clearer separation.

Fourth, there's the model of Wikimedia. Discussions that affect all Wikimedia projects happen on http://meta.wikimedia.org/ . They used to happen on http://en.wikipedia.org/ . Moving the discussion to a "meta" site stimulated awareness of other Wikimedia projects.

Fifth, there's some value in getting people to start using shared: more. --(WT-en) Evan 12:08, 7 July 2006 (EDT)

Actually, you can count me on board if we can get something like Ryan's suggestion going. It doesn't necessarily need to be a merged recent changes page, but a simple link to Shared would get the job done. Is it feasible to merge the Shared and language expedition recent changes page? -- (WT-en) Andrew Haggard (Sapphire) 12:15, 7 July 2006 (EDT)

Honestly, I don't care much about whether those pages are on the wikivoyage en: or shared:, the situation that we have to read and post in English will not be changed at all. In other words, it doesn't /can't feel any merit for most Japanese people especially from the aspect of improvement of language barriers (perhaps most of other non-English speaker will be the same, and that is the most important challenges (and concerns) for us, I think).

And I wonder how many Japanese wikivoyagers know and daily use/check the shared, actually. Personally I take some effort to increase chances to expose the shared (such as making a link on ja: front page, put "+ 画像 (shared)" comments whenever I pick up some images from shared and put them on the ja: pages), but, just a few Japanese wikivoyagers use/check shared frequently, I'm afraid. As is often the case with us Japanese, we would not dare to read English pages even if they have very useful and/or important information.

So if we want to elevate shared's responsibility and performance to the multi-lingual platform, we have to make some device such as:

• (At least we have to) Make shared's multi-lingual front pages to explain the minimum but fundamental concepts, goals and functions in each language.
• Make logo (like wikipedia commons) with brief explanation of each language and put it on each language's front page and/or clicked images (with brief comment like 「この画像はウィキトラベルシェアードから呼び出されたものです。」("This image has called up from wikivoyage shared.")) etc.

Fortunately shared's responsibilities are mainly focused on the repository of images, and the pages we have to translate into are not so many so far, I think.

As for the platform of the discussions, umm... I think it is much difficult. Perhaps we have to wait the improvement of the automatic-multi-lingual translating systems (have to wait for another couple of years or decade(s)?)

This is quite my personal opinion and of course it is not on behalf of the whole Japanese wikivoyage community. Anyway I copied Evan's message to me to ja: traveler's pub with brief Japanese translation. If we get some other comets or opinions, I will translate them and put them on this page.--(WT-en) Shoestring 06:27, 9 July 2006 (EDT)

I agree completely with everything Shoestring-sensei said. (WT-en) Jpatokal 01:37, 10 July 2006 (EDT)

Move it to Shared. (WT-en) Ryan's suggestion regarding Recent Changes to include changes to Shared: would be interesting to try. If it causes problems, we must however be prepared to take a step back. (WT-en) Riggwelter 17:44, 9 July 2006 (EDT)

Anyone care if I get started on moving our policy/tech pages to Shared? -- (WT-en) Andrew Haggard (Sapphire) 17:54, 9 July 2006 (EDT)

Perhaps we should wait a bit until we get some reaction from other language versions? I know (WT-en) Evan has been in touch with a few people out there...perhaps they haven't had the chance to say something just yet. IN any case, Evan should give some sort of final word on the issue. (WT-en) Riggwelter 17:57, 9 July 2006 (EDT)

Andrew, I'd like to at least give the idea a few days to percolate; I figure for big changes at least a week. I'd also love to hear from more active en: users, since they'll be the people most adversely affected by the change. --(WT-en) Evan 20:45, 9 July 2006 (EDT)

Moving these pages to Shared is a fine courteous gesture with my support, but it's really little more than that, since I can't see any way to get around the unfortunate need for discussions to be in a single language (and for that language to be English). It will require some effort among people on every Wikivoyage to move outside their :XX scope, but I hope that'll work. - (WT-en) Todd VerBeek 19:47, 9 July 2006 (EDT)

Agreed here too, this is mostly a symbolic move. I'm not entirely sure the symbolic benefits outweigh the practical hassle and the danger of discussion falling off the radar for most people, but I think it's something we need to do to prepare for the long run. (WT-en) Jpatokal 01:37, 10 July 2006 (EDT)

I think it's 80% symbolic and 20% practical. One practical side-effect is that we'll do some inventory on our Project:Namespace index attic and move what's important to all Wikivoyagers. A second is that we'll make it easier for go-betweens and other non-English Wikivoyagers to find information, since multilingual discussions won't be spread out all over en: in different talk pages, logbook entries, and pub sections.

I hope that having a combined Recentchanges on each language version will make the danger of things falling off the radar a little less problematic. --(WT-en) Evan 11:05, 10 July 2006 (EDT)

I'm all for it... I was just thinking that it would make sense for things like discussing autotranslation in particular. I think the combined recent changes is a good idea and folks can also use their local RFC pages to draw special attention to issues on shared. (WT-en) Majnoona 11:35, 10 July 2006 (EDT)

Sorry for the kind of belated comment, but yeah, thumbs up for this proposal too! And I don't think it'd be just a matter of being nice to the other language versions at all. Although we'll have to stick to English on Shared for a while (even the UN had to pick out a couple of working languages, why wouldn't we?) I guess that moving to Shared would save us go-betweens and users a lot of work following what's being discussed and decided and affects "our" language versions. Reporting "back" (en -> other language) is something that should and could be improved and that move would help it a lot. I also think that en: would benefit from it because 1) users not interested in technical/policy discussions will have a "cleaner" Wikivoyage to work on; and 2) Shared could work as a shortcut for any good ideas coming up at whatever other language versions to reach en: and others. Besides, the combined recent changes list is an excellent idea (thanks, Ryan) and would (maybe together with a combined watchlist, if feasible?) prevent discussion from "falling off the radar" of current en: users. Finally, I think that Shoestring's idea of multilingual front pages for Shared (automatically detected, like Wikivoyage proper) is also very good, count on me for the translation job. -- (WT-en) Ricardo (Rmx) 21:26, 18 July 2006 (EDT)

OK, so, I think most people who've posted here are in the positive... any objections to starting this process for the end of this week? --(WT-en) Evan 09:07, 18 July 2006 (EDT)

Nope. Go for it. (WT-en) Riggwelter 04:27, 19 July 2006 (EDT)

I've started with the bug reports and feature requests. While I'm at it, I've tried to streamline the process a bit by splitting reports into separate files. The new homebase is wts:Project:Technical requests. It's still rough, and lots of discussion and refinement is welcome. --(WT-en) Evan 11:18, 13 August 2006 (EDT)

Feature requests + Bug reports -> Technical requests

I think it's kind of unfair to expect people to know which problems require new features, and which problems require bug fixes. It's mostly a matter of perspective, anyways. So, would it be reasonable to combine Project:Feature requests and Project:Bug reports into one page, Wikivoyage Shared:Technical requests? I realize that it would make a very big page, but I'd like to break it down with sub-pages. --(WT-en) Evan 11:53, 2 July 2006 (EDT)

Provided we can come up with some better way to organize the pages, that works for me. Sub-pages will help, but it would also be nice if the "Technical requests" page included a brief description of the issue and was somehow categorized (by priority maybe?). Currently it's a bit daunting to try to figure out what are "pie-in-the-sky" feature requests and what are requests that have a good chance of being implemented soon. -- (WT-en) Ryan 12:18, 2 July 2006 (EDT)

What about a table? It could be generated by hand at first, until we figure out the format, then done automatically based on tags in the individual tech request pages. --(WT-en) Evan 13:17, 2 July 2006 (EDT)

Move it and set up a table as a first try. (WT-en) Riggwelter 17:44, 9 July 2006 (EDT)

How about putting it on Shared:? After all, it is a common "wish list". (WT-en) Riggwelter 09:01, 18 July 2006 (EDT)

Yes, that was the idea posted above. I very much like it. --(WT-en) Evan 09:04, 18 July 2006 (EDT)

So it was...silly me. (WT-en) Riggwelter 04:30, 19 July 2006 (EDT)

May I suggest we use "Wikivoyage Shared:Technical issues" rather than "Technical requests"? Not all tech q's are requests. (WT-en) Riggwelter 06:17, 22 July 2006 (EDT)

More pages to be moved?

I came to think of something...there are in fact several pages that could/should? be moved to Wikivoyage Shared. We should have some sort of wish list/discussion regarding which these pages could be. I can come up with a few:

• Project:Feature requests (as discussed above)
• Project:Bug reports (as discussed above)
• Project:Go-between reports -> liaison reports
• Project:Multilingual statistics
• Project:Language version policy

etc etc... Ideas, anyone? (WT-en) Riggwelter 05:48, 19 July 2006 (EDT)

I think also the Project:Expeditions for new language versions, and probably a lot of the other expeditions. --(WT-en) Evan 08:40, 19 July 2006 (EDT)

Does the move tab work for moving between en: and Shared? -- (WT-en) Ricardo (Rmx) 13:19, 1 August 2006 (EDT)

No. Wouldn't that be nice? In any event, I've moved the Language Expeditions to wts:Language Expeditions. --(WT-en) Evan 12:22, 3 October 2006 (EDT)