FlightGear wiki:Village pump/Archive 2014

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

MediaWiki updated to 1.22.0

I've updated MediaWiki to the latest stable, 1.22.0 today. Please report bugs if you find any. For a list of changes, see mw:Release notes/1.22

Gijs (talk) 15:00, 26 December 2013 (UTC)

Found bugs

• Clicking the category link at the bottom of some articles will give a fatal error. For clicking the Category:FlightGear at FlightGear will give the error message: Fatal error: Class 'Services_JSON' not found in /home/wiki/wiki/extensions/CategoryTree/CategoryTreeFunctions.php on line 224.

—Johan G (Talk | contribs) 03:44, 28 December 2013 (UTC)

The CategoryTree extension relies on a function that was removed as of 1.22.0, so the extensions needs some fixing. I've disabled it for now.

Gijs (talk) 13:01, 28 December 2013 (UTC)

Yay, CategoryTree is back. Thanks Gijs!

—Johan G (Talk | contribs) 19:50, 6 May 2014 (UTC)

• Also, the mobile theme results in an error: Fatal error: Call to undefined method MobileFormatter::setHtmlMode() in /home/wiki/wiki/extensions/MobileFrontend/includes/MobileFormatter.php on line 62 (works fine after selecting desktop mode).

Thanks,

—Philosopher (talk) 03:59, 28 December 2013 (UTC)

I forgot to update the mobile extension. Works again ;-)

Gijs (talk) 13:01, 28 December 2013 (UTC)

• In the CategoryTree the FlightGear category appears empty. The solution is reported at mw:Extension:CategoryTree#Member counts are wrong, gray arrows ► are shown instead of ►. It's a minor problem but the solution looks easy, for what I can tell.

--Bigstones (talk) 00:27, 11 May 2014 (UTC)

Unfortunately that doesn't seem to help...

Gijs (talk) 11:11, 11 May 2014 (UTC)

Got any ideas for a better name for this page?

As this is for this page in particular, see the talk page.

—Johan G (Talk | contribs) 15:44, 5 March 2014 (UTC)

Template for announcement of changes and new features

From a forum PM from Hooray (posted here with his permission):

hi, whenever we announce a new feature, we typically need to do this in three places:

• newsletter
• changelog
• the docs (corresponding wiki articles)

so far, we have always copied & pasted things, I would prefer to have a single template for this instead, something like {{Announce|version|description}}

This could add announcements to each release cycle (i.e. 3.2 currently), and we could maybe automatically add things to the newsletter and the release changelog.

Like I said, I would like to avoid redundant efforts, i.e. less copy & paste

Do you have any ideas on how to implement this using existing wiki means ?

Ideally, we would create a new announcement, like for example "canvas mouse button support", and could then use this announcement in all 3 places by calling the corresponding template.

Thanks

My take is that to use a separate template for each new feature is not a good idea, but if I understand him correctly his intention is to gather up each months new features in one template.

Any thoughts on this?

—Johan G (Talk | contribs) 17:14, 5 March 2014 (UTC)

Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments.

I am thinking of restructuring the way we're writing our newsletter by focusing on our "ugly stepchild", namely the "changelog" - as others like Torsten have pointed out, we should ideally be writing the changelog as early as possible - but the truth is, it's mostly forum people contributing to it, and it's not seen too many edits. The newsletter is working a bit better for us. So I was thinking of how to unify both worlds - especially keeping in mind that our changelog encompasses basically 6 months, i.e. 6 newsletter editions. 

So I am considering to split up our newsletter into a handful of building blocks and use a few templates, so that additions are added through a few custom templates, that would automatically add things to the changelog.

The changelog would then be written by contributing to the newsletter  and using the proper templates, such as e.g.:

{{changelog|version=3.2|category:aircraft|type=updated|announcement=The 747-400 and 777-200 have received extensive updates, and are now both using the new MapStructure-based NavDisplay framework|screenshots=|videos=}}

The changelog would then  be procedurally assembled by processing all templates for the corresponding release cycle.

I would even consider locking the changelog itself, and making it just a template that references the stuff included via templates.

We may however benefit from a few additional mediawiki extensions. But otherwise, I am hoping that the changelog is going to be more comprehensive, while the wiki would become more "formal" - we could obviously still support additions without using changelog-templates, i.e. those would be excluded.

thoughts / ideas ?

(CC'ing Philosopher, because he's been doing some template stuff, too)

Need to come up with a template that handles announcements, primarily for the changelog and the newsletter. There's a mutual relationship here, but the newsletter is much more popular, i.e. sees more contributions and more activity overall. Changelog writing is still a chore. But basically 6 months worth of newsletters are equivalent to a single changelog, we only need to establish some framework around this - and then the whole changelog could be mostly based on newsletter contributions. It would greatly help to request people to make announcements ALWAYS using 3rd person speech, so that things can be directly copied from the forum/devel list to the newsletter/changelog. That's kinda the idea here. It would reduce our workload quite significantly

• Changelog
• Newsletter
• Devel List
• Forum
• Website

—This unsigned comment was added by Hooray (Talk | contribs) 21:25, 24 April 2014‎ (UTC)

I will probably have to take a look at this now and again to think about if and how this could be done. I assume Hooray is aiming at having each newsletter and change log built up mostly from "instances" of a template like in the above comments.

There are pros and cons with this approach, as with any. I think that one of the cons is that even the slightest overhead and/or complication might scare away a few contributors. But at the other hand I fully understand that reading through six months of newsletters + forum posts + devel list posts are not that fun either (though I would guess that is not how things are done ;-).

Slightly off topic is that I would like to see a section in the change log mentioning changes that will break backwards compatibility. I first saw such a section, "Breaking changes", in the change log of MedeiaWiki 1.22 (perm) when the software of this wiki was updated, and figured it would be a good idea. This could be useful for things like for example figuring out whether FlightGear x.x can use World Scenery y.y.

Even more off topic I think that the wiki/newsletter/devel list/etc are rather blunt tools for keeping an up to date change log. My gut feeling is that there are tools for that around, and even if we do not use them we might borrow some ideas from them, hopefully without bringing a lot of red tape(!).

—Johan G (Talk | contribs) 20:14, 27 April 2014 (UTC)

Interesting subject! I think going through just 6 newsletters by hand is more rewarding than coming up with complex templates that will increase the entry barrier of the newsletter and still require summarising/rewordings afterwards to fit the concise format of a changelog. Introducing a template on the wiki won't take away the forum/devel list scanning that's required as not everyone contributes to the wiki.

I do support the "breaking changes" idea though ;-)

Gijs (talk) 19:18, 1 May 2014 (UTC)

Very dispersed Boeing 777 articles!

Hi, I got interested in Flightgear and was taking a look at the Boeing 777 articles and noticed that it was incredibly spread out.

Each aircraft has it's own page with information to varying degrees of completeness. Having a look at the A330 articles, they are much more 'aligned' and it's a lot easier to find stuff. Maybe this could be something that could be done with the Boeing. Since both seem to be very similar, I'm thinking that there could be a common page on help and tutorials respectively, with the individual type pages catering to unique information. I started on some stuff but pretty quickly figured out it was a better idea to check here first :)

--Manfred (talk) 11:55, 25 March 2014 (UTC)

Doing a simple search for pages containing "777" (see this link) I quickly see what you mean.

I assume that the different versions may have different authors and thus probably are slightly different from each other when it comes to handling and completeness. It might be a good idea to start by going through each of the help pages and tutorials (preferably while playing with the different aircraft at the same time), as well as having a look at help dialogues and any readmes in the aircraft packages.

Making a common page, while highlighting differences between the different versions, could probably help other users a lot and may perhaps be a help for aircraft developers to use features from more complete versions to improve the other ones as well as help motivate harmonizing handling like for example key bindings.

If I understand your intention I can not see why anyone would do anything but trying to give you helpful hints, after all this is a wiki. :-)

One hint for starters is to begin working on a page as a subpage to your user page, like for example User:Manfred/Boeing 777 Autopilot (I just moved it) and then moving it to the article namespace when you feel it has reached the level where you are comfortable with it (though this is not by any means necessary, it's just that I like doing so myself).

—Johan G (Talk | contribs) 16:40, 28 March 2014 (UTC)

I am interested to help, this page could be a model of what we could offer : 777-8 Dreamliner

-- F-JYL 21 April 2014 09:32

Bash and DOS syntax highlighting

Daemonburrito found that we can use syntax highlighting for Bash. I guess that means that we could use syntax highlighting for most Linux (and possibly also Mac) command lines. Looking at mw:Extension:SyntaxHighlight GeSHi I find that we also also probably can use that for DOS prompts.

—Johan G (Talk | contribs) 07:24, 5 May 2014 (UTC)

We've had that extension installed for a while now. Everything that's listed at mw:Extension:SyntaxHighlight GeSHi#Supported languages is supported, plus Nasal.

Gijs (talk) 11:23, 5 May 2014 (UTC)

I'm aware of the list, but was not aware that syntax highlighting could be used for shell programming (and hence shell promts) and guessed I was not alone.

Basically added the topic to highlight (pun intended) the possibility to do so. I should probably also mention it in Help:Formatting#Syntax highlighting.

—Johan G (Talk | contribs) 13:53, 5 May 2014 (UTC)

A plan for a reorganization of the wiki

There is an ongoing discussion on User:Bigstones/Essay:A plan for a reorganization of the wiki. Please comment on its talk page, to avoid scattering the discussion. This "section" is only intended to inform about it. --Bigstones (talk) 12:53, 7 May 2014 (UTC)

The new progress bar icons

I just changed icons that {{progressbar}} is using and would like some constructive feedback.

Some things I have noted myself is that while I used a blend of the colours used in the old icons and in some of my other icons, these icons have a much larger coloured area and thus might have a little high contrast.

In any way I am going to let this rest for a week or two and follow it up then.

—Johan G (Talk | contribs) 01:05, 10 May 2014 (UTC)

After having made them a tiny pixel smaller (from 16 px to 15 px) and having done no other changes I seem to be liking them more and more, so I leave them in their current state.

—Johan G (Talk | contribs) 18:13, 24 May 2014 (UTC)

Category:Support

As it seems that support organization is a priority, I created Category:Support. I hope the name is generic enough to avoid misunderstandings... but I thought better to have a bad one, than nothing. I'll try to put there everything on support I find so that it can be better organized (merged/split and then cleaned up). --Bigstones (talk) 13:06, 11 May 2014 (UTC)

Hi,

I didn't read through all of your ideas yet, but isn't "Support" a rather obscure term? Everything could fit under that branch, so we'll end up with yet another giant category; which you tried to prevent, right? Or maybe I'm just missing the bigger picture...

Gijs (talk) 13:23, 11 May 2014 (UTC)

Hi, I figured out (edit: led to figure out) that support organization is a major problem. There's a lot of "support" related articles, 2-3 articles only on OpenGL. I hoped that this name could indeed be wide enough, and that in case it could just be renamed. Troubleshooting seemed to narrow to me on the other side, but if you think that would be better I can change it now (waiting for response before proceeding).--Bigstones (talk) 13:29, 11 May 2014 (UTC)

Take Settings for slower graphics cards for example. It's categorised under Category:Performance tuning. I would expect that to be a sub of Category:Support. Anyone looking for articles on how to improve performance can check that category then. I don't expect anyone to go through a very broad category with 100s of articles to find info on a rather specific subject.

Or maybe I should reword my comment into a question: What would be the use case of Category:Support?

Gijs (talk) 13:39, 11 May 2014 (UTC)

PS: I know we have a lot of bloated categories on this wiki, so I'm glad you've brought all this back on the agenda ;-)

With the example: I confess I was probably deceived by the presence of some development related stuff in Category:Performance tuning. I thought it would be better to separate development and usage. Framerate is either a user issue, or a developer's aim. I think the two can be separated. The problem is I moved out the most of it! I should consider the contrary. I'll undo. (I currently have like 20 open browser tabs so it might take me some time).

The use case however is: gather support articles so that a maintainer can split/merge them to make them more organized. Once that's done, there won't probably be more than 10 articles, and if there are, still one can subcategorize. In the above case, I just took the longest path, but given the lack of tools I confess I just wanted to get started.

--Bigstones (talk) 14:00, 11 May 2014 (UTC)

... I must confess also that after undoing, I feel the urge to redo that again. The two non-support related articles, GIT Performance Tests and Howto:Use the system monitor (where btw, the "profiling" section might be directed to core developers?) would have no place if I move this category into support. That's also why I moved it into Development. Let me know what you think, also regarding the Support category name.

--Bigstones (talk) 14:24, 11 May 2014 (UTC)

FlightGear screenshot categories

I have been thinking about this for quite a while. When I was categorising the images, I gave the categories with the FlightGear screenshots quite cumbersome and long names.

I guess the discussions with Bigstones, in particular my reply here (see second paragraph under 2.) might have stirred up some old dust for me. :-)

The cumbersome and long names has a couple negative effects. Firstly they are way longer to type than should be necessary, secondly, and more important I think, the probability that they show up in the upload wizard probably is rather low as they all begin with "FlightGear..." (what was I thinking, like if someone would upload a bunch of X-Plane screenshots here). I guess that by beginning most if not all screenshot category names with "Screenshots of..." the chances they would be used will increase.

In addition to that some of those categories are way too large and need to be diffused (broken down into smaller categories).

I have noted that a lot of aircraft images have been added to the aircraft article categories. I would prefer if the screenshot categories associated with different kinds of aircraft (e.g. fighters or airliners) would be subcategories to the screenshot categories and that those screenshot categories would be a subcategory to the category for those kinds of aircraft. I have at some point started to try mimic the structure of Category:Aircraft by type in Category:FlightGear screenshots of aircraft by type, but got distracted or forgot about it for a while. Someting similar might be needed for the cockpit screenshots.

The note about intended contents should also mention that these categories are intended only for in-sim screenshots from FlightGear.

In conclusion I suggest, and would like feedback on, the following:

Current category	Suggested new category	Alternative new category	Comment
Category:FlightGear cockpit screenshots‎	Category:Screenshots of cockpits	Cockpit screenshots
Category:FlightGear cockpit close-up screenshots‎	Category:Screenshots of cockpit details	Cockpit close-up screenshots
Category:FlightGear dialogue screenshots‎	Category:Screenshots of ‎dialogues Category:Screenshots of FlightGear dialogs‎	Dialogue Dialog box screenshots
Category:FlightGear exterior screenshots‎	Category:Screenshots of aircraft	Exterior screenshots
Category:FlightGear interior screenshots	Category:Screenshots of cabins	Cabin screenshots
Category:FlightGear scenery screenshots‎	Category:Screenshots of scenery	Scenery screenshots
Category:FlightGear screenshots of aircraft by type	Category:Screenshots of aircraft by type	—	Should only contain categories
Category:FlightGear screenshots of vehicles	Category:Screenshots of vehicles	Vehicle screenshots
Category:FlightGear weather screenshots‎	Category:Screenshots of weather	Weather screenshots

In essence it is a huge bot job, except for the diffusion of the largest screenshot categories.

—Johan G (Talk | contribs) 15:57, 12 May 2014 (UTC)

As I might have said already, I'm ok with it and in particular I agree that images would be easier to find if in their own branch. The only thing, I think it's not going to last if the upload wizard doesn't enforce the use of a subcat of "Files", or at least, suggests that area in some handy way (i.e. not a written notice). Maybe the CategoryTree could be included (like with templates) to help finding the right category? It's hard to figure out a good one by typing characters one by one.

--Bigstones (talk) 21:49, 12 May 2014 (UTC)

Created the category pages as above, except for Category:Screenshots of ‎dialogues, which I found a bit ambiguous. I named that one Category:Screenshots of dialogues in FlightGear‎ instead.

I have also added a request at the bot talk page (permalink)

—Johan G (Talk | contribs) 17:59, 13 May 2014 (UTC)

Did the move to Category:Screenshots of aircraft by type by hand. Was only a few files.

—Johan G (Talk | contribs) 18:46, 13 May 2014 (UTC)

I hope I'm not late, I noticed only now, but dialogue tends to be used more as in "discussion between two", while the GUI elements are usually spelled dialogs. I guess that more than real confusion this distinction would cause just minor hilarity, but... you never know, you might find in there screenshots of radio chat with ATC. (being not a native english speaker, here's my ref.) --Bigstones (talk) 19:20, 13 May 2014 (UTC)

Well spotted, good reference as well and most important not too late. Thank you! I was wondering a bit but guessed that dialog was more or less colloquial as dialogue seemed correct with both my browsers English and American English dictionaries. Swedish schools teaching (very!) British English probably have something to do with my spelling as well.

Changed the request on the bot page from Category:Screenshots of dialogues in FlightGear‎ to Category:Screenshots of FlightGear dialogs.

—Johan G (Talk | contribs) 14:06, 14 May 2014 (UTC)

Having separate image categories or not?

One thing that keeps nagging me is that all Wikipedias I have been able to read and some I can hardly read (English, Swedish + German and French) have separate categories for files/images. There is probably a reason for that (I am guessing at mainly ease of finding images for articles and possibly also for bandwidth reasons).

The upload wizard is borrowed from Wikimedia Commons (but is it properly attributed?) where pretty much all categories are for files/images. While I am not aware of its technical details I see few if any efficient ways it could be modified to only or primarily suggest image categories. As I see it it would require a fresh and updated list of categories that in one way or another would require some manual intervention.

Two things I have done so far is to re-categorize images and that I have begun trying to link the nodes to the nodes in the branch with the article categories by putting the image categories in the article categories (this is done on a very small scale though).

Questions is though: What is in the best interest of the users? Should I keep on having them separate or should I just let it grow wild(er)? It could be an interesting experiment though it would require a lot of work if it turns out less favourable.

—Johan G (Talk | contribs) 22:02, 10 July 2014 (UTC)

I saw you implementing this at some of my airport screen-shots and immediately adopted it on other images. I think your idea of separating those categories would help us puting a link at the end of each article which says: "Media about :XY". Thats why I think all the other wikis provide separated categories. That's the only way to get linkable categories which only contain media.

--August (talk) 22:18, 10 July 2014 (UTC)

Conventions on discussion conclusions

Sometimes proposals don't get the attention the proposer might have hoped for. Of course, everyone's involved in their projects, and following discussions in "recent changes" isn't easy, so nothing personal, my question is very practical.

Sometimes these proposals need help from others (like my "remove redundant categories") so it's pretty clear that one will have to wait and retry/insist for that. Some other times though (like my above "Category:Support" topic - with which btw I did some mess moving messages around) one could easily continue on his/her own. In such cases, I feel that lack/loss of attention means "Ok, I don't mind if you do that, in case, we'll discuss the results" (like for the FAQ update - btw, thanks to the reviewers of my cuts). If this is correct, I'd like to add it to the Help:Maintenance page, because it could help getting more things done and avoid misunderstandings. Oh, and by what I said, if I don't get answers, I'll take it for granted :D

--Bigstones (talk) 12:43, 13 May 2014 (UTC)

I have found the lack of feedback to be discouraging at times, but at other times I have just went ahead and done things the way I would like to have them done, like for example my reorganisation and extension of the help pages, as well as adding the "Discuss!" link to the left side menu.

I would guess that you draw the right conclusion with the statement that "Ok, I don't mind if you do that, in case, we'll discuss the results". The very most of the times that is the way to go. The good thing with a wiki is that it is so easy to revert a change (i.e "View history" tab → Go to topmost edit → Click the "undo" link). If if things go really wrong most things can be salvaged from the page history (though it can be a lot of work at times). ;-)

—Johan G (Talk | contribs) 17:03, 13 May 2014 (UTC)

Editing JavaScript files ?

Moved here from Talk:Portal:Wiki#Editing JavaScript files ? (permalink) since this might affect all users.

I think, at some point, I saw someone editing JavaScript files here (Johan_G or Gijs probably) - what is involved to do that ? Any links/pointers ? Okay, found something at MediaWiki:Common.js Is it also possible to create custom JS/plain text files without any wiki markup ? Are my privileges even sufficient ? --Hooray (talk) 21:11, 2 June 2014 (UTC)

Nope, was not me. Javascript files is as far as I know currently limited to MediaWiki:Common.js. It is apparently possible to change some settings so that one can add "user javascript pages" (as well as "user Cascading Style Sheets"), see the WikiMedia Wiki pages mw:Manual:$wgAllowUserJs (and mw:Manual:$wgAllowUserCss).

Both can be useful for testing stuff before including them in the "common" (i.e. site wide) files, as well as for personalizing the look, feel and functionality. I do not know what issues they could cause or if we have the permissions to change it. Maybe Simon and Gijs are the ones who can do it.

—Johan G (Talk | contribs) 04:40, 3 June 2014 (UTC)

MediaWiki updated to 1.23.0

I've updated MediaWiki to the latest stable release (1.23.0) today. I'm now updating all extensions, so some things may be broken temporarily. Please report bugs if you find any. For a list of changes, see mw:Release notes/1.23

Gijs (talk) 12:04, 8 June 2014 (UTC)

readability and quality of articles - quoting statements from the forum useful?

In the last two weeks I'm trying to debug something so I wanted to find some needed information in the wiki. Instead I stumbled on articles full of quoting meaningless and partly false) statements from the forum. I don't see the meaning of this, as it influences the readability of the wiki more and more in a negative way. And I don't see why this is in any way important or helpful to users. I guess this known user wants simply highlight some certain facts, but the way he is doing this is far away from any quality standard known from wikipedia.org, educational books and similar stuff on the web. As I could see former discussions about this issue had been useless. I have two articles about helicopter flying and helicopter-fdm in the pipeline, but I fear that those articles will be also filled up with useless quotes from the forum. So what quality standards the wiki is using? Wouldn't be a simple footer with a link to the statement better than inserting quotes? --HHS (talk) 09:33, 17 August 2014 (UTC)

Hi HHS, assuming that you are referring to my edits: those are primarily about coding issues, so it may not be obvious to you if/how those are useful, but there are a number of very concrete features that have materialized by "bootstrapping" things like this over the last years.

Now, whenever you start an article, or add significantly to it, you are obviously free to take over maintenance and "veto" any changes that you disagree with.

As you can easily verify, I am not at all involved in anything relating to helicopters, so be assured that I won't interfere with any of your contributions in that department - that is, unless there's relevant feature requests and discussions to be summarized - in which case, I would consider any relevant additions to be outside the scope of the two topics you mention.

If in doubt, I'll hereby promise to get in touch with you upfront, should I desire to contribute to any of "your" articles. So there's no need to use any blackmailing tactics by making any of your potential contributions dependent on whether a certain contributor agrees with you or not.

The discussions you are referring to were specifically about the newsletter, where it was primarily Gijs who stated that such quotes should be cleaned up, and I have stated that I won't interfere with any such quality standards, but -like you- I would simply prefer to have such quality standards established first.

Like I said elsewhere, I do not even disagree with the arguments made, but obviously it takes much more time to rephrase and summarize discussions than copying relevant statements directly to the wiki. Still, some concrete features (in terms of code) were very much based on such summarized discussions.

Besides, I am really not sure why some people are turning into drama queens, and even attention junkies when it comes to certain contributions - especially people who have no significant/visible track record of contributing to the wiki in any major way?

Obviously, this doesn't apply to people like Gijs, Johan_G and Thorsten whose feedback is obviously valuable-but I find it hard to believe that someone who -allegedly- "wanted to find some needed information in the wiki" would be affected by contributions, or even discussions/flame wars, in completely unrelated wiki articles-if that's the case, I would suggest that you may need help to properly use the wiki-for which you can get in touch with any of the admins, including myself - we'll be glad to provide all the assistance that you may need, including help with editing/improving articles.

As a fellow wiki contributor, I happen to find massive edit histories confusing, i.e. all the maintenance work done by Gijs and Johan_G is hard to keep track of-but otherwise, I don't usually participate in discussions that I am not affected by. So, I find it kinda fascinating how you are apparently affected by flamewars taking place on very much unrelated talk pages ?

Thus, I am looking forward to your contributions and I am offering to walk you through the necessary steps to integrate your changes properly, without being affected by completely unrelated articles, and their discussions. If there are any helicopter related articles that contain "meaningless quotes" in your opinion, please do feel free to either remove those (you can add a note or HTML comments tag to easily hide huge sections), raise the issue on the article's talk page (using civil language preferably), or simply point out those articles here, so that I can take a look.

Once again, like I previously said, flame wars and disagreements are always unfortunate, but they come with the territority, and usually it takes at least two - and certain language is more likely to elicit behavior that we as a community find destructive - but apparently, there's also quite a bit of behind-the-scenes networking going on, so that subjectivity gets lost quickly.

As I previously said, on wikipedia (or even just the FlightGear forum), your language would have gotten your comments censored, and your account quite possibly banned temporarily - so whatever your intentions were, you were almost certainly contributing to the problem, not the solution.

Now, I didn't take any actions, because I am obviously not objective, and because I don't normally get involved in moderating stuff - but whenever two parties (like i4dnf and myself) decide to escalate a discussion beyond a certain point, it is up to them to deal with the terms - you shouldn't just show up and get involved without also expecting to be treated accordingly, especially given your choice of language - no matter if your hobby/profession is psychology or not, the kind of name calling you started would have been absolutely inappropriate elsewhere, especially for someone who's trying to be authoritative about a discussion that he hasn't even be involved in at all.

And exactly the same thing happened a couple of days ago on the P51d's talk page where you were trying to "moderate" things in a rather blunt fashion - in the meantime, I have been in touch with hvengel via PM and exchanged a number of PMs with concrete suggestions on potential Nasal related issues (that you seem to be entirely unaware of, but still feel qualified to comment on ...), so that I simply disregarded your edits and tone.

Finally, if you're interested in becoming a moderator to help moderate the wiki or forum, I suggest to get in touch with Gijs or Curt to get you set up - help is always needed and appreciated (I never asked for any of those "privileges", I prefer unencumbered discussions personally) - and I am more than willing to hand over the corresponding duties to you if they agree - but would suggest that you try to follow your own advice about applying good quality standards, but also an appropriate tone - while resisting the temptation to get involved in debates that you don't fully understand.

All this doesn't mean however that I wouldn't agree with your comments on having a quality standard established. Or that I wouldn't appreciate your contributions. --Hooray (talk) 14:23, 17 August 2014 (UTC)

I am a strong believer in that a text (including illustrations), and more so a large collection of text like for example this wiki, should be both descriptive, concise and well structured. As for articles being concise, I am not a big fan of all the quotes, though I can see some of them useful. There is a lot to say about lengths of articles, sections and paragraphs, and the sometimes unfortunately combined lack of both being not very concise and not very descriptive, that really, really does not help reading those articles. There is also a lot to say about structure in articles by the use of section and subsection headings and in particular between articles.

Many articles strongly related to each other leave a lot to be wished for. There is often a huge amount of overlap and in addition there is often a horrendous need for having to read through related articles that in turn would require reading through the first article and then some to be understandable. I consider it totally unacceptable. Together with the diffuse verbosity of some articles it makes it really hard to penetrate the subject in question.

As for my many small edits with rather large summaries, I have my preferences set up so that my edits by default is marked as minor. While it may not be obvious at first, those edits can quickly be hidden by clicking Hide minor edits at the top of a history page. Unless I forget to uncheck This is a minor edit, only edits that will be visible, in particular in articles, will not be submitted as minor edits.

Finally, as for the a bit too heated debates about edits on this wiki (dare I say quibbles) that has little or nothing to do with the discussion pages they were posted on, I have actually considered putting an identical message on a few users discussion pages asking them to take a few steps back, calm down and consider what they have posted, where they posted (i.e. will a post there be useful), and if that really had to be posted, as well as blocking each user for 24 hours (three users I will not name, you can figure out who you are, and I pretty much do not care who started).

—Johan G (Talk | contribs) 17:09, 17 August 2014 (UTC)

As can be seen in the logs, Gijs has just begun drafting some kind of style guide - I guess some more feedback would be good. But no matter the outcome, I don't mind adjusting my behavior/contributions accordingly, or adapting the Instant-Cquotes according to the requirements laid out there.

However, overall, I'd suggest to keep a healthy balance here - some wiki maintainers have increasingly strict requirements, and are obviously trying to adopt wp's best practices. Then again, our main issue is not having good ideas and coming up with guidelines, it's having the manpower -and time- to actually apply/enforce those.

Which is something that also applies in the core/fgdata/scripting department: There's an increasing amount of contributions that wouldn't have passed a review a few years ago - but like I've mentioned a few days ago: some "immature" contributions have meanwhile allowed "unskilled" (=new) contributors to become domain experts.

The same thing could very well happen in the context of the wiki: Back when we discussed certain wiki changes (such as making you, Johan_G, a wiki admin) - the whole idea was about turning an avid contributor into an expert over time, by providing the time, expertise -but also a playground and "grace period"- to experiment with changes, even if those may be relatively immature in the beginning. Meanwhile, you have become an expert when it comes to wiki templates - and I'm always grateful for any advice/help in this area.

And this can be seen in many other FG areas. We've seen this particular debate come up a number of times on the forum, and generally end-users are not too happy about having stringent requirements.

And there'd be at least half a dozen features that wouldn't be in FG today if fgdata requirements were similarly elevated/enforced (including the PFD/ND, Avidyne code etc).

Likewise, censorship/banning is a questionable measure, too - it has rarely, if ever, served us really well when dealing with real end-users (i.e. not just bots). Besides, in that case, you may want to get in touch with Gijs/Simon to have my account status downgraded/revoked, because I am not sure if you can really ban a fellow admin (I think I am in the same group as you).

But regardless if I remain involved in wiki maintenance or not, if any admin considers to use banning on real users, banning guidelines would probably be appropriate, too - i.e. could be based on wp (verbatim). Which would help ensure that certain tactics/language remain off limits. And it should also help to move such discussions to the User: namespace, so that people don't stumble across them accidentally - even though I am not sure that this would have prevented the 3rd user from interfering like he did...

But even apart from the fact that I generally don't consider censorship/banning appropriate tools, I would have been in a bad position to make this judgement, given that I was the one responding to those attacks in an equally-heated tone.

Never mind, I'll check if I can ban myself right away :-) --Hooray (talk) 17:37, 17 August 2014 (UTC)

Hello Johan

Thanks for your answer. I'm studying to get a vocational school teacher, the last 6 months I was working as a freelance lecturer at a nursing school. So I not only have to read a lot of books, text and writing informative handouts, also had to create a lot of educational text for my students. Not always easy. For both sides, the students and me, it is important to get the needed information in a short time. At my university text is considered as scientific when the language is: comprehendible using short easy-to-read sentences , objective and unemotional. Though this wiki of course does not have to be seen scientific, we probably want the same: spreading knowledge. So I think the same rules applies to this wiki.

So in my eyes text full of quotes from the forum doesn't help here. Sometimes (but only sometimes!) it is needed to highlight certain facts with statements, therefor a quote can be helpful. As you said. But articles like [[1]] aren't very helpful, not for user or (future) developers, and wasting space.

So I'm totally against such articles and especially the useless use of quotes.

How to deal? Proposal: www.wikipedia.org has a nice feature, they sign good articles with a star. Maybe we should do the same, so it is an orientation for those writing an article here. I think it is better then setting up "rules", especially as readability is also subjective.

--HHS (talk) 19:13, 17 August 2014 (UTC)

Oh, I just read through the whole Manual of Style. Everything is said there, especially about quotations and the use of it. Thanks!

--HHS (talk) 19:20, 17 August 2014 (UTC)

Just as input from one fairly new FG user/developer, to answer the original question: I did find one of the articles with many quotations from the forum to be quite useful. The Status of AI page (http://wiki.flightgear.org/Status_of_AI_in_FlightGear) had a lot of bits of discussion pulled in from the forums that I probably never would have taken the time to find on my own, and it helped me quickly wrap my head around the different aspects and approaches to AI in FlightGear and what kinds of improvements have been talked about. I suppose this type of article could need to be either pruned or updated as time went on, though, as the content would become less and less relevant as the discussion moves on.

--chriscalef

@chriscalef: Thanks for actually providing a developer's point of view - it's really appreciated. Like I said elsewhere, I do fully agree that the style of such "collections of quotes" is very poor-but, we have many articles and features that started out as "stubs" exactly like you say. And we cannot possibly expect newcomers, interested in doing development, to do this degree of "research" in the archives, at the very least, it would be very unfriendly to keep pointing potential contributors to the archives like this and probably raise the barrier to entry, too - especially, because search terms are pretty specific.

But we also cannot be expected to create proper write-ups for each frequently raised topic on the devel list/forum.

Which is why those pages with quotes were/are created, and are being updated as time goes on.

I have been in touch with a number of contributors and developers to see if we can find a solution that keeps all considerations in mind, while still keeping in mind the degree of involvement and stakes people, and especially developers (current ones, but also future ones), have.

Obviously, given the number of important areas in FlightGear, competence and expertise vary widely among all contributors. And core developers may not necessarily be in a good position to judge the quality of of FDM/helicopter or 3D modeling related articles - and it seems that aircraft developers may not necessarily be in a good position to judge the quality/degree of usefulness of core developer quotes kept here.

Indeed, there's postings to be found on the forum from around ~2010 when I said that a property-tree based 2D rendering API could not work fast enough, and when I suggested that native Nasal bindings should be used instead - equally, write-ups like the original Canvas proposal were critically discussed/dissected by other contributors-meanwhile, as we all know, User:TheTom has proven all of us wrong with his Canvas system.

So I guess, that goes to show that everybody can be wrong-and proven wrong, even by newcomers, including even people involved in the project for years.

For now, I'll opt to stay out of this to allow all parties to remain level-headed... If anybody would still like to get in touch, please use my talk page or send a forum PM. I am sure that we can find a way that addresses all concerns, without possibly harming the project by applying quality standards that might kill off discussions/features prematurely. Thanks --Hooray (talk) 14:36, 19 August 2014 (UTC)

@chriscalef:

Are you aware that some of the quotes describing the "Status" are completly outdated? So I doubt that it was really useful. As an example the very last statement by Detlef Faber. Ground vehicles are now supported since a whole while (2-3 years?), they don't bank. The date of the quotes doesn't name the year, just the month.

Btw. most of the quotes are by "Hooray" himself. Instead of quoting himself, he could wrote a small summary of all this: much more informative and more easy to read.

Nethertheless: There is a style guide, which pretty much say everything. So no need from me to discuss this further: massive quoting is not wished! Point. --HHS (talk) 16:24, 19 August 2014 (UTC)

The issue is not as simple as you are trying to make it sound, we're still talking about various pros & cons here - regardless of the whole style guide, and regardless of the fact that I do agree with all stylistic concerns voiced so far. The reasons for quoting myself is that I am trying to summarize frequently-raised topics, and those quotes obviously help with that. But the quote you are referring to is not mine but is based on a posting made by DFaber in April 2014 (as you could have easily verified by clicking the link next to it!):

here's my wishlist part 1: Disable the banking when turning with Ground Vehicles. There are Ground vehicles in FG, but mainly Trains, which I haven't been able to utilize for Cars. Also Cars need to lookup Ground elevation which AI Aircraft don't do too. FG determines submodel hits on AI/MP Objects by square Boxes around the Aircrafts Origin. These are too wide to be useful with Ground Vehicles and small Aircraft. Some more Size opions would be useful. When a new Target Heading is selected AI Aircraft don't turn harder than 30 degrees. It would be good to be able to configure this per Aircraft. I'd like to specify Model specific Properties like Livery, Type in the AI Scenario file. Right now I need to create and set them within the nasal section. These are some from the top of my head. More to come ... — DFaber (Fri Apr 25 2014). Re: AI support. (powered by Instant-Cquotes)

And based on looking at the C++ code a while ago, I have to agree with DFaber (and flug for that matter) that there are still various problems when it comes to controlling AI models from scripting space that are not supposed to behave like airliners/aircraft. I don't know how familiar you are with C++ code and the AI system in particular, but I also don't quite see how those comments were conflicting with your intentions to contribute to helicopter related articles. I would really prefer this to remain constructive and not turn into another pi**ing contest. I am sure that you have good intentions, but it seems hard to bring those across properly. And maybe that's in part because you do not belong to the intended target audience of such quote collections? Thanks in advance for trying to keep this discussion "civil" though. Semicolon.--Hooray (talk) 18:10, 19 August 2014 (UTC)

Again: http://wiki.flightgear.org/FlightGear_wiki:Manual_of_Style#Specific_recommendations.

Then: Please keep your thoughts about the AI system, my intention etc. out here. They do not belong into this discussion here.

The quotations don't show the complete date - even if at the end you still have to verify every source. That is what I wanted to show you. The fact is, Detlef is wrong here (ground vehicles don't bank), but people reading those quotes in this official wiki thinks it is true. The same Emilian already told you.

--HHS (talk) 21:09, 19 August 2014 (UTC)

PAF Team wiki Page

I would like to know if creating a PAF team wiki page would be a good idea ? i don't know if this type of page will be appreciated, because some page who talk about virtual airlines were deleted and listed on one page. But I think my situation is different (we are not à virtual airlines, but we are a french community in the french community) . I just think that this page would inform people who see "PAF team" on aircraft authors or when PAF team is quoted on the wiki.

This page would be written like that :

• Introduction
• Activities
  • Flight school
  • Multiplayer flight
  • Developpement

What do you think? you have specific suggestions or reservations Thank you for your opinion --Alexis (talk) 19:35, 2 September 2014 (UTC)

I think it could be a good idea. Even more when considering that some FlightGear users might be more comfortable around people speaking their own language. There seem to be a few other communities, like for example FlightGear UK (FGUK) and Vive FG! that are rather unknown mony FlightGear users. The thing with the virtual airline pages is that there have been a lot of failed startups that leaves an unmaintained page with rotting links.

I do not think that these pages should be all to detailed, like for example listing all aircraft and their current development status or all events. That would just be another maintenance burden for someone from those communities. It probably would probably be a lot better to give overview and some highlights and link to the sites of those communities for the details (for example by linking to hangars and event subforums or websites).

Maybe it could be a good idea to mention on some aircraft pages that they mainly was developed in a certain community and link to that page.

What do you other think?

—Johan G (Talk | contribs) 21:15, 2 September 2014 (UTC)

Persian/Farsi language pages

Copied from User talk:Touradg (permalink).

Hello friends, I would like to create the Persian page for Flightgear but I get the following error:

A database query error has occurred. This may indicate a bug in the software.

Any idea?

Thanks

--Touradg (talk) 07:06, 16 November 2014 (UTC)

Feedback on Template:GitStatus requested

Have a look at Template talk:GitStatus#Updating and improving the status template(s) for details.

—Johan G (Talk | contribs) 22:47, 17 December 2014 (UTC)

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.