User talk:Bigstones/Essay:A plan for a reorganization of the wiki: Difference between revisions

← Older edit

User talk:Bigstones/Essay:A plan for a reorganization of the wiki (view source)

Revision as of 15:39, 9 May 2014

26,138 bytes added , 9 May 2014

m

→‎Article versioning: splitting and response

Hooray

Administrators

20,741

edits

@@ Line 1: / Line 1: @@
+== A plan for a reorganization of the wiki ==
 Hi,thanks for taking the time to write down all this. I do agree that improving the wiki structure would be great. Then again, we'll want to do that without introducing any "breakage" - thus, it would be important to do this alongside the existing structure, possibly in some form of "sandbox", with just a few articles (e.g. picking the most popular ones). Also, please keep in mind that the current state of things already represents hundreds of hours contributed by volunteers like you. Roughly 8 years ago it was Gijs who didn't like the wiki structure and then spent dozens of hours coming up with a new scheme, but he made sure not to break anything by implementing his own structure as a suggestion alongside the existing system. That is something that I would also suggest to do here. If you need an extensions to be installed, better discuss this with Gijs first, so that he can review your ideas and then get in touch with Simon (who's maintaining the server).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 08:49, 6 May 2014 (UTC)
 : Hi, I will of course discuss all this with the maintainers (by posting about it on Village pump and Documentation forum). For now this is "private" only because writing it down helped to clarify my mind on some things. I didn't consider possibility of breakage, so that's going to be interesting. I'll soon publish this thing, when ready.--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 09:55, 6 May 2014 (UTC)
@@ Line 51: / Line 52: @@
 I never looked at the thread, but I could explain what's involved here - however, it's not exactly straightforward, because our scenery is compiled "offline", and it also uses the same data. There are several dependencies in place here that are not obvious to bystanders. We've had quite a few discussions about doing this sort of thing. So we generally discourage rebuilding your own navdb, unless you know exactly what you're doing (including the TG side of things)-which would mean that you wouldn't be asking the question :-)  --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 07:57, 7 May 2014 (UTC)
 : I asked that because I've found some hints about "contributing to navaid data", in a "notice to volunteers" in a modeling article (sic) (see [http://wiki.flightgear.org/index.php?title=Modeling_-_Getting_Started&diff=prev&oldid=70555 here], 3rd red block, then moved [[Volunteer#Making airports|here]].). I wanted to know if that's actually open to volunteering, like sending Robin new apt.dat's. (I'd actually like to understand what navigation data has to do with scenery. I am curious about that ~100MB file generated any time I add/remove some scenery.) --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:03, 7 May 2014 (UTC)
+:: contributing to new/improved navaid data is indeed appreciated, but different from actually using it in FlightGear. To better understand the motivation behind asking people for navdb updates (R.Peel), you need to understand that the original data source (DAFIFT) has been discontinued, so that the corresponding data is no longer freely available to projects like FG/XP etc. According to R.Peel's website, they're currently planning to come up with a web-based interface that would allow people to contribute directly in some kind of wiki-like fashion, which is something that we've been discussing on our forums for years. We have some contributors who worked on similar tools, so it would make sense to coordinate things a little-but otherwise, contributing improved data doesn't necessarily mean that you'll be able to directly use it in FG. The ~200MB file you are referring to is a SQLite database created from those plain text files, so that we can better support geospatial queries (=more efficient spatial searches). In addition, it's intended to reduce the startup/initialization overhead, by building the DB once and then using the pre-created cache subsequently. In theory the feature itself is great, but it has caused quite a bit of headache over the years, because there are numerous issues that only show up for some people, such as the process taking hours to re-build the cache, weird localization issues and other performance issues.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:00, 8 May 2014 (UTC)
+== Approaching CategoryTree ==
+Thanks for reactivating [http://wiki.flightgear.org/index.php?title=Special%3ACategoryTree&target=FlightGear+wiki&mode=pages&namespaces= this great tool]. If I'm correct, [[:Category:FlightGear wiki]] is the root category. I'll make a review and report, can't wait to turn everything upside down!!! In the meantime I will post here any questions that arise, and try to get used to check [[Special:RecentChanges]]. I'll also search for the tool I want... but a first try deeply reduced my expectations, I hope in your better confidence with the world of wikis. I hope changing categories hasn't to be done only by manually editing articles.
+So. First questions:
+# Some main categories are there for technical reasons, that is, all of them but Articles and Files, where "real" contents are contained. Right?
+# Files categories are separated from articles ones. When I upload an image, is the category I choose limited to subs of [[:Category:Files]]? If not, I'll have to include files in the review of the tree. (in the link above I included only articles).
+# What do I do with non-English articles? In most cases I can figure out what they talk about. Are categories universal with respect to this or non-English articles are sort of an independent wiki?
+# Inside [[:Category:Articles]], I'm not sure I understand the Documentation cat. What isn't documentation in a wiki? Aren't aviation articles documentation as well? (this question should go in the review actually)
+# Any major changes will only be planned and go in the review. But meanwhile, can I safely do the following?
+## Remove articles from parent categories, if they're already in subcategories
+## Move articles to existing subcategories
+## Create subcategories where to move '''clearly''' too generally categorized articles
+:: (note that the above will begin to shape a tree with leaves, but won't break the "web" structure, that is, I won't follow "one article, one category" yet. Actually, I expect the above to be common maintenance)
+--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 21:06, 7 May 2014 (UTC)
+: 1. Yes, though one other thought I had when creating [[:Category:FlightGear wiki]] was to also have it serve as the root for the pages in the various namespaces (i.e. Main/Articles, File, Help, Portal, Template and User), though I chose to put both of the articles in the "FlightGear wiki" namespace in that category as well.  In other words I intended to have in it the root categories for pages in each namespace as well as [[:Category:Hidden categories]] and [[:Category:Wiki maintenance]] that did not really fit well anywhere else.
+: I should also mention that I created that category because there seemed to be a few separate trees that did not connect at the roots while I was hunting down all but one of the uncategorised categories (I seem to be unable to edit the only page linking to the last one, [[Template:Ru/Черновик]]).
+: 2. You can chose any category when uploading files.  In the last months/years a lot of files have been added to article categories.  While that ''could'' work I feel that it would be messy and make it harder to find the right image when browsing for images specifically.  Personally I would prefer if a file category was added to a article category instead of all it's images.  In some cases that would work splendidly in other cases not.  For example [[:Category:Screenshots]] fits well under [[:Category:Software]], but i do not think that [[:Category:Icons]] would fit well under any article category.
+: When it comes to newly uploaded aircraft images I feel in part that I am at fault.  When I categorised the the bigger part of the existing ones (hundreds of them, and still not done) I unfortunately did not think the category structure and naming through properly, so those ended up in a few large heaps of screenshots, the worst one probably being [[:Category:FlightGear exterior screenshots‎]] (nearly 500 images).  I also showed poor judgment in category names.  I could have skipped FlightGear in the category names (talk about being implied ;-).  Had they instead been for example "Aircraft interior screenshots" they would also probably be easier to find in the upload wizard.  Though all this is easy to say now afterwards...
+: 3. My tip in regards to the non-English articles is to use the language links and use the categories of the corresponding English article.  Currently the non-English articles are the ones remaining to be categorised (except for new and a few old ones), I have kind of saved them for last and focused on the easy ones.
+: 4. I think I created [[:Category:Documentation]] to bind together [[:Category:Howto]] and [[:Category:Core developer documentation]].  I guess it just went on from there with not too much thought into it mainly aiming at connecting related categories and articles, again probably when hunting down uncategorised categories.
+: 5.1, 2 and 3  Definitively!  I would be doing it myself if it wasn't such a chore, lol.  And yes indeed it ''is'' common maintenance.  :-)  When creating new category names, it is well worth the time to come up with meaningful category names, which as I mentioned above, is sometimes easier to see in the rear-view mirror... ;-)
+: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 22:40, 7 May 2014 (UTC)
+: I forgot to mention it above, but one of the technical limitations of the MediaWiki wiki software is that one indeed have to edit each categorised page to change its category since they are categorised by the use of the [[Help:Categories#Categorizing pages|category links]].  Thankfully if ''all'' the pages in a category should need changing the category, in essence "moving" the category from one name to another it can be done with a so called "bot job".
+: About those FlightGear screenshot subcategories:  I have thought about to at some (undefined) point in the future request [[User:Gijs|Gijs]] to set up a bot job to change those names into more meaningful ones.
+: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 22:57, 7 May 2014 (UTC)
+:: 1. is not very clear to me.
+:: 2. I agree with you. Maybe something can be done to force the interface to use only Files subcats, and a bot can move the "leaked" files. Writing a bot is not the first of my dreams, though.
+:: 3. They're a bit noisy actually. But maybe that job can be automated too.
+:: 4. Well, as grandparent categories should have not many subcats, it can be changed any time.
+:: 5. Great! (I wonder why in so many years of existence of mediawiki, nobody ever created a drag'n'drop interface for such stuff.)
+::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:08, 7 May 2014 (UTC)
+::: About your reply to my answer to the first question. Is it the namespaces that are confusing or was I a bit confusing?  Maybe I should rephrase myself, I tend to both be rather verbose and to stray from the subject. ;-)
+::: To sum it up as short as possible I created it as ''the'' root category, since I found that there wasn't ''one'' when I categorised uncategorised categories.
+::: The different namespaces (speaking of namespaces in general, not the categories) contain wiki pages that are used in different ways.  For example category links will show up as categories at the bottom of pages, templates does not need the "Template:" prefix when included into a page using curly braces, only pages in the main namespace show up in simple searches etc.  That, and that the English Wikipedia have a root category in a similar fashion[http://en.wikipedia.org/wiki/Category:Contents] is the reason why I have created root categories for the pages in each namespace.  That said the root category was not meant to be reserved only for "namespace categories" though I feel they fit nicely in it.
+::: Did that help?
+::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 14:02, 8 May 2014 (UTC)
+:::: Definitely, thanks. --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:18, 8 May 2014 (UTC)
+===Development classification ===
+Ok. Now I have another couple questions:
+* What's the reasoning behind the distinction between [[:Category:Developer Plans]] and [[:Category:Development projects]]? Does it make sense to tie development plans to a developer? Or is there a difference between plans and projects? (ok, the former are just dreams, but the latter don't guarantee anything.)
+* What exactly makes development ''core''?
+*#Changing C++ in fg/flightgear Git repo
+*#Changing C++ in any fg/ Git repo project
+*#Coding in C++
+*#Any coding related activity (i.e. including nasal and python) integrated in fg
+*#Like above but also separate tools like osm2city
+*#Anything but aircraft/scenery development (excluding also little nasal scripts for animation purpose)
+*Is shader development core? is it sorcery?
+--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:48, 8 May 2014 (UTC)
+: * Developer plans are plans by individual developers, i.e. collections of ideas and publicly stated goals, without anybody actually working on stuff necessarily, i.e. long-term stuff that people are interested in.
+: * development projects are projects that people are actually working on
+: * yeah, it very much makes sense to associate developers with plans, because there are more ideas and feature requests than be handled realistically. But whenever an idea or "plan" is associated with a known contributor, that idea/plan has obviously more weight than some random suggestion coming from someone external to the project. And certain plans have even much more weight than others, e.g. [[Plan-zakalawe]] or [[User:TheTom]] are fairly representative simply because those are the two main guys handling the majority of commits for the time being[http://forum.flightgear.org/viewtopic.php?f=5&t=22119&p=201125&hilit=#p201125]. Having people linked to ideas/plans is a good thing in my opinion, because we -as contributors- can actually learn who supports certain ideas. For instance, whenever I support a certain idea, I am willing to provide mentoring, and I know of others like Philosopher, who also provide additional support for certain projects.
+: * core development is C++ development, usually handled by core developers, i.e. people with commit access - or at least C++ development by people who are working towards getting this committed, i.e. not some branch that is intended to be never merged, aka irrelevant to the main project (fork).
+: * scripting in Nasal/Python is generally not considered core development, unless it touches core development stuff - e.g. in the case of [[Canvas]] which makes certain C++ code obsolete through scripting space bindings.
+: * osm2city et al are not considered core development, but the people working on those features are hoping to eventually re-implement some parts via core extensions.
+: * shaders are middleware/base package development, i.e. do not typically require SG/FG commit access or C++ changes, and are thus not generally considered "core" development.
+: * Overall, I'd suggest not to tamper with categories/areas that you don't understand, i.e. that require interpretations of different types of contributions-those categories are unlikely to be relevant to end-users anyway. And people who are looking for this info will typically also understand the various differences. Cleaning up such things is low priority in my opinion, someone able to build from source and program in C++ is unlikely to be affected by proper/improper categories, so no need to waste any time here-better focus on popular articles and categories first. Existing contributors, especially core developers, are unlikely to benefit greatly from such wiki improvements, and to be honest: most of us don't care at all - there are very few core developers who actually contribute to the wiki, let alone care for formalizing such differences and boundaries.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 23:16, 8 May 2014 (UTC)
+:: Thanks for spending the time, I fully understood the Developer Plans part and the last part is practically the "safe area" I wrote about (kinda scared by the amount of data you harvest and pile up everyday). However, if this is how things are, maybe that could be renamed to Core developer plans. It might be a minor change, but clarifies the boundary, or that might get filled by random plans (I myself put some stuff there and will remedy). I didn't expect core devs to be so few. PS: Sorry for the "NOPE not c++" commit, I should have read a couple lines more!
+:: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:59, 8 May 2014 (UTC)
+::: no problem (galvedro's work may actually be overlapping with C++/core stuff soon), I just wouldn't prioritize stuff that's really only of interest to people who are either already contributors or who're interested in becoming core developers, that's kinda a niche and once someone is at that stage, they're not going to be bothered by certain inaccuracies or confusing wiki categories.
+::: Maybe better coordinate such things with Gijs and Johan_G to find a more self-contained area that benefits from your additions ? Being "all over the place" could be potentially problematic as long as there are concepts and connections that still need to be understood.
+::: I am just saying this because we're obviously grateful for anybody volunteering here, especially people willing to do "chores" that really only 2-3 guys are doing otherwise (actually, I don't typically help with such things at all, so it's really just Gijs & Johan).
+:::Developer plans vs. core developer plans - we do have developers/contributors who have plans outside core development (e.g. Nasal), so that's where that distinction came from. Then again, nothing is set in stone - it should just be kinda plausible to most people. There's nothing wrong about "random plans" as long as there's a '''contributor''' (not just end-user) that can be associated with such ideas, either willing to work on them, or at least support/mentor people.
+:::Otherwise, we'll just end up with tons of unsupported ideas & plans. As I said, it makes a huge difference for us as a project and community of contributors, being self-organized, just '''who''' exactly supports certain ideas - this applies certainly to anything that is not just a trivial weekend hack, but requires many weekends of spare time coding.
+::: For example: This is kinda how Gijs' [[NavDisplay]] project took shape (no core development either): Zakalawe was supportive of it (it aligning well with his own plans to get rid of certain C++ code and unify/modernize our OpenGL code via Canvas), so that others (Hyde, Philosopher, I) knew that this would be a worthwhile project because we had "community/contributor" support (not just through ideas, but helping hands). And others like TheTom also knew that there were a handful of contributors involved, so our RoR is much greater because contributions are magnified by others working on similar problems. Yet, we had to identify overlapping areas and decide what we wanted to work on - splitting up the whole thing into components, so that the [[MapStructure]] folks will normally not have to touch the [[NavDisplay]] stuff (and vice versa). Likewise, there are similar projects, like a Nasal/Canvas animation framework or a PFD framework that simply have certain community support, i.e. in the form of people willing to provide help/support.
+:::So we are using "contributor momentum" to evaluate popularity of ideas and to determine if we're interested in teaming up with others who have similar/overlapping ideas. Having just a huge collection of "random & unsupported" feature requests or ideas is begging for trouble, and is the main reason why the issue tracker is not intended for feature requests, i.e. to remain useful for people who are actually able to do certain work. Which is where the wiki shines: Ideas/plans gathered here by contributors (instead of end-users) obviously matter more, even if they should never be touched in months[http://forum.flightgear.org/viewtopic.php?f=4&t=1563&p=11299&hilit=#p11299], they're representing long-term direction. And obviously it also matter just how active a contributor is at any given time, ideas and plans have more weight if someone is still involved and very active, vs. others who are no longer involved or very inactive. We have some fairly active fgdata developers whose contributions are not quite in line with ideas laid out by core developers who are meanwhile pretty much inactive, obviously activity beats inactivity. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 07:35, 9 May 2014 (UTC)
+=== Article versioning ===
+::::I'm all over the place *to* understand concepts and connections. I do that because I still believe that there should be a better separation between stable documentation and projects documentation, for the good of normal users, not core devs! While learning scenery development it was a major annoyance stumbling in old surpassed project pages, and I kept having the feeling that I didn't know everything I should. I didn't trust much the portals, either. The forum was a great support in this and it's '''wonderful''' that nobody ever answers "use the search" (which is the standard in Italian forums). Nevertheless, no surprise people say the wiki "just sucks". It took me some time to decide to join and I was not far from staying away.
+::::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 14:07, 9 May 2014 (UTC)
+::::: Having better separation between stable/development articles/docs would be great in my opinion, too. We've  been discussing this for years actually. I am still in favor of supporting branching/forking articles, along with tagging for each version. Currently, it's too late - but it's certainly worthwhile to discuss and consider beginning with 4.0. So far, I am dealing with this by using lots of '''notes''' and adding version specific stuff to the template. But I am convinced that we should follow wikipedia here, i.e. introduce the notion of article tagging, and requiring stable articles to be reviewed before being published, see for example:
+:::::* http://forum.flightgear.org/viewtopic.php?f=23&t=7064&p=66581&hilit=articles+tagging#p66581
+:::::* http://forum.flightgear.org/viewtopic.php?f=3&t=18240&p=170735&hilit=tagging#p170735
+:::::* http://forum.flightgear.org/viewtopic.php?f=3&t=18240&p=170749&hilit=tagging#p170749
+:::::* http://forum.flightgear.org/viewtopic.php?f=3&t=18240&p=170543&hilit=articles+tagging#p170543
+:::::* http://forum.flightgear.org/viewtopic.php?f=3&t=18240&p=170566&hilit=articles+tagging#p170566
+:::::* http://forum.flightgear.org/viewtopic.php?f=3&t=18240&p=170544&hilit=articles+tagging#p170544
+:::::* http://forum.flightgear.org/viewtopic.php?f=3&t=18240&p=170735&hilit=wiki#p170932
+::::: the main point being here that you don't need to read through dozens of postings/pages (BTW: Yes, that could also mean USE THE SEARCH!), but that discussions are generally not as useful as establishing mechanisms and infrastructure and "enforcing" things - the FG community is generally pretty clever, but we're extremely unorganized and even chaotic at times, we've had countless good discussions and proposals to fix some very long-standing FG issues (including quality of wiki docs), but usually that's the only thing that really materializes unfortunately: talking, and very clever suggestions that end up forgotten in the archives. Now, with regard to wiki tagging and stable/unstable (versioned) docs, I am fully supportive of it and willing to help get this going. And both, Gijs & Johan_G have commented on the issue too - it just needs to start somewhere. I would suggest to prepare this for 4.0, draw a line, and begin splitting things accordingly. Obviously, it would be up to other volunteers to help with older releases, but I am only interested in doing this for 3.2, or better, 4.0. Even if this is something that neither of us is going to tackle anytime soon, this would warrant having a dedicated article about the whole idea, because people keep reinventing the same solutions... --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:39, 9 May 2014 (UTC)
+== Tools for a better "new article" interface ==
+I was looking for the supertool, while I saw these and thought they could be useful for a better "new article" interface:
+* [https://www.mediawiki.org/wiki/Extension:CategoryHook Extension:CategoryHook]
+* [https://www.mediawiki.org/wiki/Extension:CategorySuggest Extension:CategorySuggest]
+* [https://www.mediawiki.org/wiki/Extension:ManageCategories Extension:ManageCategories] (despite the name, it manages a single article categories.)
+--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:44, 7 May 2014 (UTC)
+: I would agree that having some kind of article creation wizard would be kinda useful. I am still looking for a good way to unify handling for identical contents, i.e. changelog/newsletter and development announcements.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:15, 8 May 2014 (UTC)
+::: An alternative to an article creation wizard could be to pre-load a skeleton page (i.e. not a wiki template), but I do not think that would help finding a category all too much.  Personally I would prefer to have neither, but perhaps there could be a link somewhere suitable to help interested users create a page using a skeleton page?
+::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 19:16, 8 May 2014 (UTC)
+:::: The file upload wizard seems to work pretty well, and a category (existing or new) could be made mandatory. There's several extensions that we could try, e.g. see: https://en.wikipedia.org/wiki/Wikipedia:Article_wizard --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:28, 8 May 2014 (UTC)
+== Bot proposal (request?) ==
+Talking about supertools, it seems what I want is a bot.--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 22:44, 7 May 2014 (UTC)
+: I think bots can currently only be run by Gijs (well, obviously also Simon as the wiki admin). Given the potential damage that may result from running a bot script, I would always ask others to review/test the bot first, and maybe run it in some kind of sandbox or sub-portal. Gijs once explained the requirements for running scripted bots to me, but I haven't yet had a real need for doing so, and I don't think "normal" wiki admins have the necessary permissions. But if there's anything that would be lots of work to do manually, I can help with coming up with a python bot/script to automate that (of course, we'd first of all need to agree that we want to proceed accordingly)--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:15, 8 May 2014 (UTC) (moved by --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 20:14, 8 May 2014 (UTC))
+:: There is actually something easy that a bot could do right now, in fact I was just reading on bots and found a java framework (I don't know python), although not looking forward for that... so I really appreciate your offer. I'm talking about point 5.1 in the above [[#Approaching CategoryTree]], I quote them:
+::# Remove articles from parent categories, if they're already in subcategories
+::# Move articles to existing subcategories
+::# Create subcategories where to move '''clearly''' too generally categorized articles
+:: There are many that suffer from that, and as that's an automatable task, it'd be better done automatically before the other two (non automatable) tasks, because those articles would get in the way and I would end up doing that work manually. E.g.: [[Requesting Technical Help]] belongs to [[:Category:Documentation]] and [[:Category:FlightGear]]. The second one is already into Documentation, so this one should be removed. It should be easy to open every article and cross check their categories. The hardest thing to do is probably preload and cache the category tree for faster lookup (if possible).
+::--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 17:59, 8 May 2014 (UTC)
+: Alternative to a bot for many tasks: [https://www.mediawiki.org/wiki/Extension:Replace_Text Extension:Replace Text]
+: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 10:54, 9 May 2014 (UTC)