(In reply to Marc A. Pelletier from comment #0)

• Search is difficult to make meaningful, as it generally cannot sort

between the two classes of overlapping subjects

This sounds like a search problem we can improve on. Can you give some concrete examples?

• User rights on Wikitech are tied to technical rights with the

infrastructure, and are delicate to delegate to the community

This sounds like a configuration problem. If we can't hand out +sysop because it has extra permissions either we need a new group with the sysop-y rights or can split the non-sysop-y stuff off to its own group.

• Namespaces are an issue, as the mainspace either becomes ambiguous or we

need to overload technical namespaces (Like Nova resources:)

More namespaces is easy if we don't want to lose meaning on them.

The downsides are significant enough that members of the community have
discussed the possibility of setting up their own mediawiki instance to take
this role. I'd rather we did not have yet another divergent code base
running and depended upon by the dev community, so I think that a proper
prod wiki would be the correct solution.

+1, if we're going to do it.

But I'm not convinced so -1. We have an awful time as it is duplicating technical content & documentation and I'm pretty sure we'll do it with this new wiki too.

I like to +1 what Chad has said above.
And two wikitech-wikis are confusing.

(In reply to Chad H. from comment #1)

(In reply to Marc A. Pelletier from comment #0)
This sounds like a search problem we can improve on. Can you give some
concrete examples?

Try to figure out how to use puppet for a labs project for instance; over half the pages are about puppet as applied by opsen in prod and it's rarely clear which is which. Same deal if you want to find documentation about DNS, etc. Things are only going to get worse if we deploy Openstack for prod work.

It's not about search quality as the subject matter /is/ truly relevant, but context gets lost.

• User rights on Wikitech are tied to technical rights with the

infrastructure, and are delicate to delegate to the community

This sounds like a configuration problem. If we can't hand out +sysop
because it has extra permissions either we need a new group with the sysop-y
rights or can split the non-sysop-y stuff off to its own group.

That's arguably true, but more complicated than first seems (especially in re 'crat etc).

More namespaces is easy if we don't want to lose meaning on them.

I think that's besides the point - Wikitech has a well-defined value as a collection of ops-related documentation and tools; and I don't expect documentation of the /workings/ of labs (infrastructure-wise) should be split - nor the technical interface.

What the point /is/ IMO is that there is a community building amongst labs /users/ and supporting that community with a Wiki is our modus operandi. There really isn't any overlap in focus - documenting usage and processes of dev-facing labs stuff is very distinct - and having a wiki for this is much more productive than spreading documentation between semi-automated Nova resource: pages and subpages of various vaguely related topics.

Please not another wiki :(

IMO content either should be on mediawikiwiki or wikitech or even meta if necessary.

As a labs user I find the current configuration a nightmare. We have stuff spread across multiple wikis, and even the wikitech wiki is a pain in the ass to find the needed documentation. Wikitech should revert to what it started out to be: a documentation wiki for production. labs and specifically tools labs need their own location for documentation. Forking namespaces is just begging for a headache/someone going postal.

One of the easiest examples I can come up with is the issue of the revision table and the revision_userindex tables.

On the toolserver there was clear documentation on both (the pros and cons of using either table) and an explanation of the rationale for such variants.

There are other examples that I can provide, but those types of factoids and documentation do not belong on wikitech, however such blurbs along with other community based suggestions/docs make working with the non-production environment a lot easier. Throwing this into an existing wiki with production documentation makes the labs users frustrated. When I am looking for something I shouldn't have have to dig through a dozen pages relating to production configuration to find the one page about the tools/labs config. Often there are minor differences between the two setups so that a user tries to follow the guide for prod, only to fail because of something in labs is different.

A wise man once told me about an ideal, once I learned it, it became a way of life. KISS Keep It Simple Stupid. We dont mix dewiki and enwiki. They have two separate communities, languages, and policies. Labs and prod are the same. If I remember a fairly notorious quote from the development/policy of labs is:

that labs will never be production and will not be treated as such.

Keep in mind that the goal of documentation is to make a subject easier to understand for someone learning it. Right now it takes someone to teach a person how to find the proper docs and differentiate between labs and prod documentation. I thouldnt be that complex of a process

Where does git documentation go? Right now it's mostly on mw.org. But look, wikitech too. Shall we duplicate it a third time for labswiki too?

All 3 audiences arguably need the info without caring much about the other two groups.

(In reply to Chad H. from comment #6)

Where does git documentation go? Right now it's mostly on mw.org. But look,
wikitech too. Shall we duplicate it a third time for labswiki too?

Documentation on how to /use/ git should live in mw.org. Documentation on how git is implemented/maintained should be on wikitech. Until and unless there is a Labs-specific git service for some reason, none of it should live on that wiki.

Honestly, that's the *easy* part.

Git is not specific to labs. Thus for the most part documentation should not be there. The best place for that would probably be mediawiki.org.

Reminds me of an old saying. Every place has its thing, and every thing has its place.

General non-production docs (general mediawiki stuff) should go on mediawiki.org

production related stuff should go on wiki-tech

and labs stuff should be on labs wiki.

(In reply to Marc A. Pelletier from comment #7)

Honestly, that's the *easy* part.

Put another, probably less snarky way... :-)

You're perfectly correct that there is currently an unholy mix of documentation and where it is located. That is a problem to solve by sorting what goes where, not by stirring another distinct set of documentation in the mix. :-)

I guess we just see the solution differently then. I'd rather have one wiki with all the infos than lots of wikis with specialized infos.

To each their own, but you asked for feedback :p

I did, and I'm grateful for it. I still think that you underestimate how hard it is for the general Labs user to find what they need in "all the info" even though it is arguably convenient for /us/ to have everything collected together.

Best of both worlds IMO is specialized wikis combined with a cross-wiki search. When are you doing the latter? :-)

(In reply to Marc A. Pelletier from comment #11)

Best of both worlds IMO is specialized wikis combined with a cross-wiki
search. When are you doing the latter? :-)

The latter *works* and has worked for like over 6 months. It's just ugly as sin though so I haven't enabled it anywhere.

(In reply to Chad H. from comment #12)

The latter *works* and has worked for like over 6 months. It's just ugly as
sin though so I haven't enabled it anywhere.

Sounds like the labs wiki, if it gets created, would be a nice candidate. :-)

(In reply to Marc A. Pelletier from comment #11)

I did, and I'm grateful for it. I still think that you underestimate how
hard it is for the general Labs user to find what they need in "all the
info" even though it is arguably convenient for /us/ to have everything
collected together.

Best of both worlds IMO is specialized wikis combined with a cross-wiki
search. When are you doing the latter? :-)

Two wikis are imho verry confusing for the general Labs user. Only some new namespaces, usergroups etc. need to created. Mabye enabling the translate extension etc. :)

Another example of where tools labs and wikitech utterly fail.

I was looking up the docs for connecting to a wiki via code. Using the toolserver wiki it was fairly easy: https://wiki.toolserver.org/view/Database_access#PHP

On wiki tech, the single search result that has replica.my.cnf is https://wikitech.wikimedia.org/wiki/Tool_Labs/Migration_to_eqiad which is utterly useless for researching what a user needs. When searching for the more generic "connect database" you get results that have nothing to do with tools.

I strongly agree with comment 4.

And with OpenStack's Horizon on the horizon (:P) Wikitech should become less crowded with technical groups and be more of an actual wiki.

In T70818#727452, @MZMcBride wrote:

I strongly agree with comment 4.

A year later, I still agree with myself. ;-)

I think this task should be declined. I'm sympathetic to having good user documentation for Labs users, but I think creating yet another wiki is the wrong approach to take.

thanks for declining . adding more wikis (just like adding mailing lists) is a common suggestion to solve a problem that usually just leads to even more confusion as now content is (more or less randomly) split between different locations.

also the whole "prod stuff here, labs stuff there" only enforces that "labs" has nothing to do with prod, while we actually want it to be less different.

Perhaps we could create some more targeted tickets around specific problems that the current Labs and Tool Labs communities have with using Wikitech and try to tackle them individually? @coren's original list was:

• Search is difficult to make meaningful, as it generally cannot sort between the two classes of overlapping subjects
• User rights on Wikitech are tied to technical rights with the infrastructure, and are delicate to delegate to the community
• Namespaces are an issue, as the mainspace either becomes ambiguous or we need to overload technical namespaces (Like Nova resources:)