Board index FlightGear The FlightGear project

Published recommendations, guidelines and rules

Questions about the FlightGear organisation, website, wiki etc.

Published recommendations, guidelines and rules

Postby Johan G » Sat Apr 18, 2015 9:22 am

Johan G wrote in Sat Apr 18, 2015 9:20 am:I have been thinking of the lack of recommendations, guidelines, and downright rules in many areas almost since I got involved in the FlightGear community. I am just relatively quiet about those things (perhaps with the exception of my essay on and about the wiki, that thankfully in part have been obsoleted).

I am quite sure that some of the arguments coming up could be avoided if there more or less would be documented guidelines, published for example on the wiki, more or less based on the consensus at a given time (and that also links back to the discussions and the rationale behind them). In some cases those could be of help in situations like the one about whether or not include aircraft into FGAddon and what can be required of those. Not having published guidelines of one kind or another will cause discussions about how things are done or not done.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5490
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Published recommendations, guidelines and rules

Postby Jabberwocky » Sat Apr 18, 2015 4:03 pm

Well, since there is no defined quality standard for the planes and we can't even pull one out of the hat, refusal of a plane by a person who tried to get himself kind of an exclusive gatekeeper position can only be considered arbitrary, especially given, that many planes in the "official" repository are not even flyable.
So, given the situation, a guideline would have to be based on a very low level atm. And of course, things are not done with a guideline about which planes can get into the "official" repository, there is obviously a need for guidelines where and in what time frame the options for decisions are discussed. Here? the devlist? Wiki? Commit logs (I don't know how that should work because a commit is after the fact). So, I guess, that needs more brain work and in the end, this is Open Soruce, so all guidelines would be more informal and non-binding while technical facts, like the ability to deny free speech are obviously the domain of "certain persons".
Jabberwocky
Retired
 
Posts: 1319
Joined: Sat Mar 22, 2014 7:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: Published recommendations, guidelines and rules

Postby Johan G » Sat Apr 18, 2015 5:05 pm

Jabberwocky wrote in Sat Apr 18, 2015 4:03 pm:Well, since there is no defined quality standard for the planes and we can't even pull one out of the hat, refusal of a plane by a person who tried to get himself kind of an exclusive gatekeeper position can only be considered arbitrary, especially given, that many planes in the "official" repository are not even flyable.

At the other hand he would have to balance between get as little yelled at as possible both from people insisting on including *everything* and people insisting that no aircraft should be included unless it has a certain high standard (as well as many people leaning to each or the other side). In addition, since there is very little of guidelines he can expect to be yelled at even more, as one could expect that contributors and users have less respect for him than some guidelines.

Jabberwocky wrote in Sat Apr 18, 2015 4:03 pm:...given the situation, a guideline would have to be based on a very low level atm.

I think I can agree on that. In addition if one would raise the standard one could expect some (admittedly less reasonable) arguments on why new aircraft would have to be so much better than some of the older ones, and why this and that contributor can not be demanded to upgrade all his older aircraft.

Jabberwocky wrote in Sat Apr 18, 2015 4:03 pm:...and in the end, this is Open Soruce, so all guidelines would be more informal and non-binding while technical facts, like the ability to deny free speech are obviously the domain of "certain persons".

I would dare say that FlightGear is very free and more toward the anarchistic side on the organization level for an open source project by this size. I sometimes yoke about how the 'cathedral' is at one end of the scale, FlightGear at the other and the 'bazaar' in the middle.*

Consider that we do not have a set in stone coding style guide (do we even have one at all?), no governing board/board of trustees/whatever etc. Have you found the forum rules? It of course have both pros and cons.

Jabberwocky wrote in Sat Apr 18, 2015 4:03 pm:And of course, things are not done with a guideline about which planes can get into the "official" repository, there is obviously a need for guidelines where and in what time frame the options for decisions are discussed. Here? the devlist? Wiki? ... So, I guess, that needs more brain work

I think you touch on one of the tricky points here. Currently things are discussed on both the devlist, the forum and the wiki. Somehow I think that users and developers should to a larger extent be encouraged to discuss the wiki on the wiki, the core development and new features needing hooks on the developer list and aircraft, scenery and all things under the "data" umbrella on the forum. Currently it is often all mixed and overlapping which kind of interferes with the transparency from time to time.


In addition, and I find this a slight bit more important than where it is discussed: When do the discussion stop and the recommendations/guidelines/rules get summarized (note that this is a rater iterative process) and finally published? Could we achieve some kind of consensus? Also, what would be needed to go through it all again?

I think it would be very preferable to achieve some kind of consensus and summarize both the guidelines and, probably just as important, their rationale as well as links to the archived discussions leading to them. I think they would be much more respected that way.

More respected guidelines based on consensus would probably also lead to less in-fighting and conflicts. In essence it is much easier to be respectful towards half of the at one time active community than towards one or two users/contributors/developers/committers. Perhaps we can get there one small step at a time... :wink:

* Referring to The Cathedral and the Bazaar by Eric S. Raymond
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5490
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Published recommendations, guidelines and rules

Postby IAHM-COL » Sat Apr 18, 2015 5:38 pm

Well... This is an interesting topic

Me, myself, following the recommendations by Hooray, am planning to make some wiki articles explaining

  • howto use effectively FGDATA next with submodules to repopulate FGDATA with as many aircraft as any user is willing
  • howto add aircraft to github, and develop using proper git techniques. --everyone can have a git of its own and need not to follow a boundary of quality sets to get his own work out there
  • how to get any non-existing aircraft into FGDATA next with FGMEMBERS. =We are a developing branch, and as such we don't expect finished master pieces. We just offer a developing platform that is great to code socially: release early, release often. Keep improving. Get others input. Get others on board of your work. get advise (issue), and help (collaborators). Don't worry about mis-steps (anything is revertable in git), it's not about the quality now, its about the potential in the future
  • how to fork any existing aircraft for a "personal view" potential spinning. This thing happens all the time, and in my opinion is great. 2 b190ds, 2 dhc6, 2 condors, 5 DC47, 2 shuttles, 2 Antonovs-12 or 22... etc. It's all for the best. Sometimes another persons fork becomes the lead and default, without making other author contributions dissapear, or even versions replacements (ask Erik). In FGMEMBER we offer as many variants of any aircraft as authors are willing to make. And all of them accessible. We can fork, branch any repository, and we don't need to make a "final call" of who stays and who goes into oblivion.
  • in GPL is about respecting patternity, not preventing forking or feeling overemotional because someone else forked your work. And here is another good WHY one never doom the commit history to dissappear. Nothing tells authorship (who did what) better than those obscure logs. Many times more effective than any AUTHORS.txt file you can ever create.

So I will definitely will be making some sort of a wiki guideline of how to take advantage of the more GPL bound, democratic, and inclussive offer that flightgear have for aircraft development: FGMEMBERS. And I put myself in the front line for any one needing some GIT-advise. ANy time (email me, PMme, or post a thread. I will be there to be of help!)

Respect to FGAddons, we all know the sort of management that repo has. And sure, I've heard a lot lately about how is "going open" and wild. Asking everyone to just commit there. Well... its a subversion repository after all, meaning giving write access to every one showing up is not a very wise idea, but that's not even something I came up with first. Its just self-evident. But the problem is that other people want to encourage everyone to keep sending patches -or tickets- and worry not, because other people can author your improvements for you. A little note on the commit log is not as efficient of an authorship recognition as it is to author a commit-id by yourself. That's just my maybe 2 or 4 cents of thought.

Best,
IH-COL
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4064
Joined: Wed Aug 08, 2012 5:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

FGAddon vs. FGMEMBERS, bus factors etc.

Postby Jabberwocky » Sat Apr 18, 2015 6:05 pm

It's only part of the guidelines discussion, but I think, FGMEMBERs is much more apt for team development, FGADDON for production planes. Which would be something to write down for the guidelines in the general info part ...
This would also solve the problem of standards (none for FGMEMBERs, for example an average 3 rating for FGADDON). Just such an idea.
Jabberwocky
Retired
 
Posts: 1319
Joined: Sat Mar 22, 2014 7:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: Published recommendations, guidelines and rules

Postby Johan G » Sat Apr 18, 2015 10:16 pm

The discussion about FGMEMBERS etc. have been split off to FGAddon vs. FGMEMBERS, bus factors etc..
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5490
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Published recommendations, guidelines and rules

Postby Johan G » Sun Apr 26, 2015 4:05 pm

Maybe I should mention that I started this topic after having seen this talk by Brian 'Fitz' Fitzpatrick and Ben Collins-Sussman.

Google I/O 2008 - Open Source Projects and Poisonous People (58 min, including also an interesting question and answer session)


The same talk but at Google TechTalks (and with another Q&A session) can be found here: How Open Source Projects Survive Poisonous People (And... (55 min YouTube video).


I saw this (as wells as the other) after having seen the video linked to in this post.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5490
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Published recommendations, guidelines and rules

Postby Johan G » Wed May 06, 2015 11:17 pm

To get back on topic I should mention that the video in my post above has a slightly misleading title.

What it is really about is how to set things up to avoid some pitfalls that lead to less time being spent on producing while more time is spent arguing.

In essence Ben and Fitz among other things discuss having some kind of (early) community consensus on guidelines published on a wiki or web page. They argue that newcomers will not try argue for something completely different on a forum or a mailing list.

In essence an explicit 'because it is right there' always works better than an implied 'because I say so'. ;)
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5490
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Published recommendations, guidelines and rules

Postby Johan G » Thu May 07, 2015 1:49 pm

Some posts have been split off to the new topic Looking for aircraft with 'paper cut' bugs.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5490
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Published recommendations, guidelines and rules

Postby Jabberwocky » Fri May 08, 2015 8:58 pm

Just as another thought in the "guidelines" conversation: As I understand the term "guidelines" it should not only include what is allowed and what not, but more essential the needed information for newcomers to get into the whole FlightGear world. Newcomers basically run through stages and not everyone steps up into the next stage and some start not at the first level but basicalle it is like

1.) No ides about how to start a plane ... need information about flying

2.) Plane has a bug ... need information about how planes are defined, need information who can help to get rid of the bug

3.) FlighGear has some problems ... need information who to trigger

4.) Triggered a dozen time, no reply ... need information how to get involved and get rid of that annoying bug myself

This is very rough and simplified and what I want to show is, that with every step the information needed changes. Should "guidelines" provide those levels of information?

J.
Jabberwocky
Retired
 
Posts: 1319
Joined: Sat Mar 22, 2014 7:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: Published recommendations, guidelines and rules

Postby clrCoda » Fri May 08, 2015 10:08 pm

Much of that is covered in the flightgear manual.
Ray St. Marie
clrCoda
 
Posts: 1228
Joined: Wed Apr 07, 2010 11:04 am

Re: Published recommendations, guidelines and rules

Postby Jabberwocky » Sat May 09, 2015 1:54 am

Ray,

yes and no. I still remember my first steps. All referred to the Cessna which was for me, back then without a joystick, virtually not controllable. Other parts were hard to understand simply because the terms were unfamiliar. So the situation for an absolute newbie is different than for someone who knows already something abut flying in general.
I think, to break it down to different information levels, but I'm not sure how to do it the smartest way yet.

J.
Jabberwocky
Retired
 
Posts: 1319
Joined: Sat Mar 22, 2014 7:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: Published recommendations, guidelines and rules

Postby Johan G » Sun May 10, 2015 5:20 pm

It sounds a bit like the New to FlightGear article on the wiki. :wink:

I guess it could be linked to from more (related) articles, so it will be easier to find (it is linked to from the main page though). As with most wiki articles I also guess it could be improved.


Edit:
My thought with 'guidelines' is that they would be more like recommendations or policies rather than more strict 'do' or 'do not' rules, as well as to be recommendations on how to behave appropriately within the community,

Somewhat related to the subject of this topic is this section of Karl Fogel's Producing Open Source Software (the two chapters Social and Political Infrastructure and Communications seem relevant as well.)

Also related to this topic is this excellent blog post by Amy Hoy: Help Vampires: A Spotter’s Guide (highly recommended reading :wink: ).
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5490
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Published recommendations, guidelines and rules

Postby Jabberwocky » Mon May 11, 2015 3:32 pm

The first part looks like the wiki article "New to FlgihtGear", the thing afterwards is, that we have a "How to contribute" but not much specific information from that point on where to find the people with expertise in one or the other area (for example, I know only that Buckaroo is a Yasim guru because I stumbled over his website when I googles very specific Yasim questions).
And the "How to behave thing" obviously only works if all are held to the same standards.
The third thing, who has which authorities, if any, should be also included. For my taste, we have lately too many authority claims that don't hold water, but any newcomer would fall for those claims.
Jabberwocky
Retired
 
Posts: 1319
Joined: Sat Mar 22, 2014 7:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: Published recommendations, guidelines and rules

Postby Hooray » Mon May 11, 2015 5:36 pm

I don't think this is too difficult to understand: in a meritocracy "authority" comes with the territory, and is soley/mainly determined by your track record - i.e. someone who spent 500+ hrs working on the bo105, ec1330 or 777 - obviously has a certain authority when it comes to the corresponding aircraft/domains - but that doesn't directly translate into any authority when it comes to forum, wiki, scenery or core development matters - whereas strong technical skills and expertise (e.g. maintaining complex GIS code like TerraGear) obviously does give you much more authority in general than "just" working on 3D models, liveries or Nasal scripts - even if you should belong to those who literally created hundreds of those.

BTW: I am sincerely sorry for anybody who needed to use google to find out that Buckaroo documented most YASim internals - this is all over the place, and not exactly hard to find ... In fact, had you even just looked at the first paragraph on the YASim wiki article, you should have found out so immediately: http://wiki.flightgear.org/YASim
In other words, you are asking for others to spoon-feed information to you that is readily available to those who are able, and willing, to look at existing resources, like the wiki.
Then again, if you think that others would also find this useful, it is up to you to roll up your sleeves to create a corresponding wiki article, and along the way, improve your own track record.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Next

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 3 guests