User talk:Kghbln/Archive 02

Archived talk | f | smw | -u-a / -u+a / +u-a / bl (e) | sm / Curated wikis:  of  ( %)

Branch template?
Would it be stepping on your toes move queries and stuff for branches into a template to generate branch pages and add a property+category so it can be neatly queried? I'm looking forward to getting some pretty graphs from that data :) --ete (talk) 18:12, 18 June 2014 (UTC)


 * Nope, since this is work in progress anyway. It is currently evolving step by step. Yeah, a property "Blongs to branch" will be most helpful since I would additionally like to have e.g. a timeline for a single branch only, etc.. Also it would simplify the brachnavigation template I created yesterday. --&#91;&#91;kgh&#93;&#93; (talk) 18:27, 18 June 2014 (UTC)


 * Utterly cool :) Ah using variables. I think a propery for branches allows even more flexibility beyond the overview pages. I just have the idea that it may be nice not just to have the website count but also percentage information. Will have a good nights sleep now. :) --&#91;&#91;kgh&#93;&#93; (talk) 20:52, 18 June 2014 (UTC)


 * SMW is fun :). I was kinda unsure how your version of the nav template worked, and variables are something I've used before. Still have some ideas on improving it (redlink to next if any websites have a version we're missing?). I think we could well add a branch property to each generator too. I was prioritizing the properties which let us query for website counts for each branch, but thinking more, it probably works best to include unofficial releases too... I'll go back and change a few things, see if it fits with your idea :). Edit: Maybe tomorrow. Sleep for now. --ete (talk) 21:43, 18 June 2014 (UTC)


 * My version worked very similar, but required the versions to be hardcoded within the rest of the page. Variables is far better since it allows to avoid this. I think it will be better to put alphas, custom versions etc. into different pages like e.g. Generator:MediaWiki 1.19.x/custom etc. To maintain an official stable insight is important I believe. --&#91;&#91;kgh&#93;&#93; (talk) 11:57, 19 June 2014 (UTC)


 * hmm would having official version queries on top, with subheadings still on the same page be okay with you? I think it makes sense to include custom versions in the general stats for branches, since, for example the Debian build of MW 1.19.whatever is still pretty much going to be 1.19. I agree that having separate official queries would be good, and that an official release only table should be at the top of each branch page, but sub branch pages seems like it would be awkward and unecessary. Could you use your handy bulk import powers to add release type official? That way we can easily do queries of the type {{#ask: Has branch number:: Has release type::OFFICIAL . Ideally, imo, we should LTS a boolean flag applied separately from release type. I'll make a mockup of what I'm thinking of so you can see what you think. --ete (talk)  21:13, 19 June 2014 (UTC)


 * Okay, see Generator:MediaWiki_1.21.x and Generator:MediaWiki_1.19.x. I've not been able to do the queries optimally due to the thing where you can't query just for the absence of a property and a lot of sites don't have Has release type currently, but it gives an idea of what I'm thinking. The timeline is official release only, there first table of results is official only, but the others are still viewable and there's no need for a bunch of subpages which would mostly not have much info/hardly ever be visited, and imo the info fits well on the branch pages. My proposal is:


 * Set alpha and beta releases to Has release type:Pre-Release (including WMF, and /WMF pages get moved to /Pre-Release)
 * Set all official releases to Has release type:Official (or Public?) (including LTS)
 * Make an Is LTS property and set it to true for LTS versions.

I will of course be very happy to set this up (I think I can do all of the necessary changes with a few mass find/replaces+fixes to templates) if you like the idea. I think it'll simplify queries considerably and give more flexibility. --ete (talk) 22:16, 19 June 2014 (UTC)


 * Hmm, how can we sort this out properly? I just wasted time on farms, so I will reply tomorrow. --&#91;&#91;kgh&#93;&#93; (talk) 20:48, 20 June 2014 (UTC)


 * Yeah we need to move LTS out of "Release type" to "Is LTS release". This will indeed solve the problem you addressed. When we will only have WMF, DEBIAN, CUSTOM and later on perhaps UBUNTU, GENTOO or others if there is enough of them around. We actually should label everything coming from WMF consistently as WMF, so we have WMF - alpha for e.g. MW 1.24wmf8, WMF - release candidate for MW 1.24.0-rc.1 and WMF - stable for e.g. MW 1.24.0, etc. Pre-release is nothing else than alpha, beta or release candidate, so we should avoid this I believe. However, we can still compile a branch page with WMF - stable and DEBIAN - stable and this is basically what is to be achieved. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 07:22, 21 June 2014 (UTC)


 * Okay, I'm on board with that plan. Everything WMF as WMF is a good idea, separating out by alpha/beta/stable for queries should work well. I'll set it up this evening unless you get to it first. I'd still be favor putting all the WMF/DEBIAN/etc releases on one page rather than splitting it up, but having the stable ones in a separate query on top rather than having loads of subpages. --ete (talk) 10:50, 21 June 2014 (UTC)


 * I have done the basic changes so far. You can very well add the Debian, etc. stuff to the branch pages. No probs here. :) --&#91;&#91;kgh&#93;&#93; (talk) 14:57, 21 June 2014 (UTC)

What do you want to work on next :)
I think we've mostly covered the Generators other than a few tweaks (unless you've got some more ideas?). I've got a bunch of ideas for tuning up and displaying extra fun data about all the parts of WikiApiary. I'm thinking Farms has some low hanging fruit (fixing queries to not hide a load of farms due to sorting, displaying stats about generators and extensions in use by each farm, sorting out the language tagging thing, making sure we're catching as many farms as possible automatically, maybe a few bulk imports of smaller ones if thingles approves), Websites is the most complex but is also the most important area of site and has a handful of improvements (though maybe best wait until we've got a decision on flags?), Skins seems to do most of what it needs to though maybe handling of clones/derivatives could be improved, Extensions has a few things to tweak (like your idea of moving the version grid out to help performance, and handling derivatives/renames nicely) but needs to be able to draw data from mw.o before it can get really fun, and.. am I missing anything?

Of course, we don't need to play with the same area of site, but it's handy having someone helping out and double checking your work/bouncing ideas off. --ete (talk) 20:02, 21 June 2014 (UTC)