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)


 * Same to you. I believe this was a great collaboration to set things up for the generators. Links to these pages are currently spreading on mw.org. --&#91;&#91;kgh&#93;&#93; (talk) 09:56, 22 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)


 * Template:Skin and Form:Skin still use tables and could use to be moved for Foreground's grid to allow responsive display. Just an idea. :-) 🐝 thingles (talk) 03:57, 22 June 2014 (UTC)


 * When it comes to generators WikiAPIary is in pretty good shape now. Surely some tweaks (e.g. going responsive) may still be done but in general ... :)
 * One thing which will be nice though is to not only display the website count in absolute numbers but also to include the percentage of the usage, on some pages in relation to all websites and on some pages additionally in relation to the websites using a particular branch.
 * Another thing, which we need to do, is to track their usage over time. I think we will need some bot that queries for the website counts and then moves them in on overview pages.
 * However the latter is something we cannot really do or should better be done by bots from the start.
 * this is . 🐝 thingles (talk) 14:58, 22 June 2014 (UTC)
 * Now I know where I got this idea from. :) --&#91;&#91;kgh&#93;&#93; (talk) 08:31, 23 June 2014 (UTC)
 * I think the websites are currently of least concern. A lot may still be done there but in gerneral ... Since ratings for extensions will soon be interconnected with mw.o we should probably focus on extensions rather than farms. So I think we should focus on extensions now.
 * --&#91;&#91;kgh&#93;&#93; (talk) 10:08, 22 June 2014 (UTC)


 * @thingles I'll have a poke around and see, but I'm not particularly comfortable with the grid yet and I never got more than passable at html in general unless I have fairly similar examples to work from and a plan. I will try, but no promises I'll be able to make something which looks/works nicer than the current setup before getting frustrated and going back to fun SMW things. --ete (talk)  11:06, 22 June 2014 (UTC)


 * this diff shows the change that made Template:Extension work with the grid. That same type of edit is what is needed. 🐝 thingles (talk) 14:54, 22 June 2014 (UTC)


 * Okay, hmm.. yea, I think I can work from that, thanks. --ete (talk) 21:42, 22 June 2014 (UTC)


 * @&#91;&#91;kgh&#93;&#93; Okay, I'll take a closer look at extensions and see what looks like it'd be good to improve. I'll probably make a couple of quick farm fixes too, but you're right, extensions are going to be a lot more visible soon and it makes sense to get them all working well and looking pretty first. --ete (talk) 11:06, 22 June 2014 (UTC)

This page is nolonger updating
Hello, I still check in on Wikiapiary often to see the progress Coasterpedia has made and recently, the line graphs have stopped updating. Is there something wrong on my side? The website has been quite slow in the past few days but I think it's due to my shared hosting which is outwith my control and it should speed up again soon. Thank you - Wikiapiary is a great insight into how Coasterpedia is doing. Coasterpedia (talk) 15:16, 13 July 2014 (UTC)


 * Great that this is useful for you and thank you for reporting this issue. The cause is not at your end. Currently MW and SMW do not play well with each other, i.e. there is a really big issue to be solved. As a result data collection of wikis may arbitrarily stop working. I just refreshed the page for Costerpadia to get this working for you again but it may happen again. So sit tight as I do until hopefully soon... Cheers --&#91;&#91;kgh&#93;&#93; (talk) 15:41, 13 July 2014 (UTC)


 * This issue has recently been resolved, so Coasterpedia should be tracked properly now. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 13:07, 5 August 2014 (UTC)

Deactivating as well as defuncting?
Here you turned active off as well as defuncting, which hides the historical graphs and gives a message about will be collected later. I've been just defuncting and using active to indicate "this wiki has been confirmed functional at some point in the past", which seems less redundant. Maybe there's something I'm missing which means doing both is better? --ete (talk) 21:14, 4 August 2014 (UTC)


 * The problem is, that defucting does not override activation, i.e. Bumble Bee will still continue to fetch data from a defunct wiki. Ideally defucting should stop collection and deactivating should not erase historic data. Quite big issue for which we have a GitHub issue already. Cannot remember which one though. Should probably be prioritised. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 13:06, 5 August 2014 (UTC)


 * huh, I was pretty sure defuncting worked fine but opt out was being ignored by the bots? Looking again, the sites with defunct true and active true don't seem to have any attempted collections showing in their logs which suggests defunct is working correctly (e.g. 100 Startup Ideas, anything else here). The bug I'm finding also only refers to Opt Out not being noticed by bots, not defunct. What makes you think defunct is getting ignored? --ete (talk) 15:58, 5 August 2014 (UTC)