Am 27.10.11 10:24, schrieb James Turner: > 'we' (the infamous FlightGear we) should probably write a wiki page of > aircraft-contributor-etiquette, so we have grounds to revoke people's access > if they break the rules. Though just about the only rules I'm aware of : > > keep it GPL; > don't modify other people's work without asking, or trying to ask; > try to avoid copy-and-pasting when you can share files or scripts > between aircraft > > ... and I only stuck the last one in because it's a pet hate of mine :) > > James
Hi James This will be nice, and I hope such a page goes also to the forum, to gitorious, the official fg site etc., when it is not already there. The last four years there are -500 (minus five hundred) commits to the fgdata repo. One will say, hah, this does not say anything about the quality of the remaining commits. But unfortunately, I guess it is a mix of different circumstances, some former aircraft contributors are not very active anymore, some left the scene, some new contributors did not get information how to get access to "the" or a "own" repo. I thought once we have "teams" working on a aircraft, i.e. one is doing the model and another one is probably doing the FDM, another team member cares probably about liveries. The team can also give user support to its hangar, probably in the forum, so there is also an easier stucture for user feedback. And maybe there are some members doing liveries or FDMs here and there, so they can be member of different teams. The team administrators decides themself if they want to work more hierarchical or less liberal ;-) "So why not split how the work could be done in future with 1000+ aircrafts". But this is fairly naiv, and I confess, I have no experience with such. Looks like there is more need for "THIS IS MY AIRCRAFT" and not for "THIS IS OUR GLIDER HANGAR". BTW. I see that i.e. QGis is working with some kind of "team repos" or also "single member team repos" to manage plug-ins and "third" contribution. Users update online directly within QGis along this repos. When a plugin does not work for the core, the plugin developer is responsible to make it work and probably has its own "support page" or whatelse. When a "subdev" needs a changes in the core, he goes to the list or the tracker and ask for changes, or contribute him/herself, probably also by merge requests. It seems to be all in one repo, but this structure gives a lot of flexibility, in my view. Cheers, Yves ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
