Attract contributors and Pull Requests!

[tngreene]

Recently, XPlane2Blender has gotten a lot more involvement with the community - from #397's request for samples to discussions about 2.8's use of collections (#450) and more, and also private testing of the converter. I've also seen in increase in users helping users (thanks @arb65912 and @lehthanis and a few others I've seen popping up recently if I am remember who is who correctly [forgive me if I'm not]). This has been joyous to see and a huge time saver! But, it isn't code, and we have a ton of features and documentation to write!

Most recently someone e-mailed two patches. Only one was added, but the other is sitting in my inbox because I don't have time to look at it, explain why it isn't pythonic enough to meet project standards rather than saying "try again and don't make the thing that... um... it isn't a good solution yet even though it works", or point to some formatting guideline besides "um... PEP8". Another person recently e-mailed and said "how can I help?" and I told them to go write tutorials on the forums and answer questions.

This. Sucks.

Between the converter and 2.8 I don't have time for Open Source development, and yet it would help so much to have code contributions and people I could talk with on Guest Slack every few days. Or even to simply write the unit tests for these features which is extremely time consuming and tedious, but has templates readily available and doesn't require much programming knowledge.

Otherwise the 2.49 converter and 2.8 support will stretch on forever.

Things I need to help automate the inclusion of community support

General needs

• [ ] Be less controlling over the project! It doesn't all have to be perfect or all the same as how I would do it, but it does have to ship. It does have to be professional because we have professional users!
• [ ] For any "Needs a style guide" bulletin it would be amazing if I could just spew a bunch of stuff to someone and have them format those notes into the style guide for me. Anytime I'm faced with the question "Should I write the spec and hope I find it useful or someone else would see it and feel inspired vs I'll just do it" I always pick "I'll just do it", and then I can't get help. Turning notes into a finished document simply takes time I don't have for something that isn't immediately useful.

(I, infact, feel like I'm wasting time writing this thing I feel like won't come to anything but more questions over how fast I can get it all done and why the code has to be so good if it could just work. Yes it has to be professional, yes we need unit tests, yes we need design decisions or the slippery slope begins and code-tumors fester and it isn't fit for payware developers, Laminar Research employees, and regular users anymore. No discussion unless you're also a professional software engineer please.)

Increasing ease of contributions to the docs

• [x] Solving #432 is something that needs being done, and can really only be done efficiently by me, but people could still be writing docs and tutorials and contributing them to the manual (https://github.com/tngreene/XPlane2Blender-docs, not the X-Plane copy which is not synced with Gitbooks.)
• [ ] Another style guide saying things like "If you're mentioning a property in the UI, using backticks, if it is an option for that property use "qoutes". "Also, use good grammer and spelling, avoid idioms and be concise"
• [ ] There is a list of things that need documenting, #286, but honestly it might be better to just start writing tutorials for what you found confusing or didn't know how to do and we'll just put them in a section by author. Making example blend files for people to look at would be good as well.

But of course, with 2.8, we'd have to redo all the screenshots we take of the UI... Is any documentation better than no documentation? Developer.xplane.com is a good test case. It has a bunch of docs that are more technical than the average user can ever comprehend them, and even I have to ask Ben what he meant by something, but, eventually you figure it out - kinda.

Increasing ease of contributing code

• [x] Automatic code formatter support such as YAPF or Autopep8, that runs on committing new changes, because it is better to just let a computer do the formatting that telling people what I like or changing it for them because I feel bad about what I feel might be pedantic.
• [x] ~Documenting differences between project style and PEP8~
• [ ] Writing specs for the things I feel people can do without stepping on toes or deep decisions about the addon or asking Ben for clarification, like the front end for the converter or the bugs marked help wanted. This is again, a place where if I could just call someone, talk about it, and then they can write the spec from the notes of the call and I could review it, it would be a big time saver
• [ ] Documented pull request workflow - how to name new branches, what to include in the pull request, etc. E-mailing people and merging and cleaning their stuff for them is too much work

Increasing ease of unit test creation

• [x] Upload and document unit test template .blend and .py file. See commit 837e90ca3480.
• [ ] Being able to tell someone the things that need testing and a commit to start at would be amazing and doesn't require any complicated programming besides filling in a template and saying

self.assertTrue("bpy.data.objects["01_has_blend_glass"].material_slots[0].material.xplane.blend_glass)

Increasing ease of people handling support cases

• [ ] This is something I've regrettably slipped on more and more. Most support tickets are resolved by "Ask for a small .blend file reproducing the problem and what exactly they're trying to do", you try and do it, it is usually someone isn't using Blender or the feature correctly or not reading the error message, and less commonly I need to write some print statements and study the code this thing interacts with, particularly for exceptions thrown. Having someone else try the basics first before I get to it would be a huge help to the community. Payware developers who want more secrecy about their files can still e-mail them directly if needed.
• [ ] The most technical part of this process is knowing where stuff is in the code base, being comfortable with print statements, and maybe PyDev and eclipse. This is easy stuff to set up once, and again, more guides about the code base and where stuff is would be a big help to get people started. But, I just never get to it.

Things that I'm absolutely never going to accept

• Incorrect or incomprehensible docs
• Code that looks like this

# gets the objects needed
def getObjectsWithMatProp(p):
    list = []
    for i in range(len(bpy.data.objects)):
        if(bpy.data.objects[i].material.whatever is 1): list.append(bpy.data.objects[i])
    return list

or anything else found in the Python Anti-Patterns handbook

• Missing or incomplete unit tests for any feature

Another alternative would be politely petitioning Laminar Research to hire me an intern or junior dev I could tell what to do everyday instead of asking for an angel to fall out of the internet and put up with the above right now for free.

2.49 converter and 2.8 is ending up to be more than one person can handle in a reasonable amount of time at a professional grade quality people rely on - These features need to go right and go right the first time. The converter will likely only be used a few times per people by people and its sets up their project for the future forever and it will be difficult or impossible merging changes between conversion attempts. 2.8 is the start of a new chapter of the program. After everyone sets up their Collections that is what we're stuck with until 2.9. There are no shortcuts to be taken here.

</concerned plea for help and understanding>

[arb65912]

I, infact, feel like I'm wasting time writing this thing I feel like won't come to anything but more questions over how fast I can get it all done and why the code has to be so good if it could just work. Yes it has to be professional, yes we need unit tests, yes we need design decisions or the slippery slope begins and code-tumors fester and it isn't fit for payware developers, Laminar Research employees, and regular users anymore. No discussion unless you're also a professional software engineer please.

Ted, I think it is important you took time and wrote that. I have read all 3 times, yes, to understand the best I can and not to miss things and here is my input.

1. Keeping in mind that documentation will probably used for people like me who had to learn the basics hard way by asking you, Ben and other friendly pro developers, I am willing to write step by step tutorial with screenshots on how to use bones for animation with axis of rotation not orthogonal with XP coordinate system. I would do it after I test myself that all bones animations work properly in 2.80 exporter of course. I know that the coding is the most important but without good documentation it would weed out many potential users.

Another alternative would be politely petitioning Laminar Research to hire me an intern or junior dev I could tell what to do everyday instead of asking for an angel to fall out of the internet and put up with the above right now for free.

That would obviously make things easier and progress faster but only LR bosses know how much they would want to "invest" in exporter. I would definitely ask , maybe it could be just a temporary position for a skilled professional.

2.49 converter and 2.8 is ending up to be more than one person can handle in a reasonable amount of time at a professional grade quality people rely on - These features need to go right and go right the first time. The converter will likely only be used a few times per people by people and its sets up their project for the future forever and it will be difficult or impossible merging changes between conversion attempts. 2.8 is the start of a new chapter of the program. After everyone sets up their Collections that is what we're stuck with until 2.9. There are no shortcuts to be taken here.

I am sorry to repeat myself as I expressed that opinion at the beginning of the "2.80 setup" discussion but I still believe that below points are crucial to success and timely release of the 2.80 exporter

1. the main objective of the exporter is to export objects from blender to XP8 format with attributes NORMAL_METALNESS and GLOBAL_specular 1 We all know how great would be to see in Blender what we will see in XP and be able to incorporate various workflows etc. BUT keeping in mind what Ted explained, we just need to make the minimum work first, objects , animations and animations with bones.
2. Keeping things simple will assure the professionalism and ease of sometimes necessary changes during the exporter development process.

I am sorry if others disagree with me but that is the point of discussion, to exchange ideas on things.

Thank you all for a great work and contributions.

[kbrandwijk]

I am a beginner X-Plane aircraft modeler (not a beginner in Blender), and as such, have a obvious big interest in XPlane2Blender. As with many tools, once you really start using them, you start running into issues and wishes. Some minor, some bigger (think 2.8 support). I was vaguely aware that XPlane2Blender was OSS, and that led me to this repo a little while ago.

I am also a software developer, so one of the first thoughts I had was (just being honest here), I'll just fork it and do what I want with it. Then again, I'm also a big OSS enthousiast, so my second thought was, let's have a closer look at the current state of the project (a.k.a. the issues), see if they more or less align with mine, and see how I could contribute. I've done this with many an OSS project in the past.

Then I came across this issue, and the situation you describe made me almost want to go back to the 'fork it' idea. I would really like to see this addon make it to 2.8, as well as some other fixes and improvements, and I would be willing to spend some serious time making that happen, but just open sourcing something doesn't immediately turn it into a community project, and if this is not, then that would not be time well spent.

I guess the two things I wonder about most are:

• Is the decision making process a LR thing, or a community thing? I see evidence of both in the issues here, but I'm unclear on this.
• Do you really have the intention of making this more of a community project from a development point of view, and related, do you simply have the time to review PRs in a timely fashion?

I hope you are willing to shed some light on these questions.

[tngreene]

Hi @kbrandwijk !

For some clarification: I am a contractor for Laminar Research and this repo is financially backed by the company, but they give me wide latitude for how to run it.

Who directs X-Plane/XPlane2Blender? Laminar Research or the artists?

I'd say we balance the needs of everyone well. Laminar Research considers the addon and content community as a central pillar of its business model - 3rd party artists are part of X-Plane itself - therefore in a way XPlane2Blender's community direction is itself the companies direction and vis-versa. Such is a healthy symbiotic relationship!

Does Laminar Research use XPlane2Blender differently than anyone else?

We have always used GPL license. We have no internal version, no payware artist version, and there is only 1 LR specific feature that's snuck in (and it is very very very very minor for an automation script we have. It wasn't my call.) We use the same tools as everyone else uses. We try to keep it balanced between everyone's needs. The only time Ben and I put down a foot is for large workflow requests or features that only benefit specific artist's needs.

Decision making for X-Plane/XPlane2Blender?

Because we've never had more than one developer really working on this, we haven't had much decision making questions about pull requests and such. We read every bug report, feature request, and e-mail that comes our way and make a decision. We have never had another developer make a serious fork, so we've never had a splitting of the community. I greatly want to avoid that.

Given that I have an admin account, it gives me near total control, but I certainly don't want to act like that with new volunteers, and I think a history of engaging with people in deep conversations on here and in the forums shows that isn't the type of developer I am.

Going forward I'd like to continue the feeling we have now, just with more like minded programmers on the team instead of just artists giving feedback.

Do you time to grow an OSS garden anyway?

I think I have time to manage 1.5 people's small pull requests, but not so much for training them. I'm hoping that developing some nice on-boarding docs can help that. I don't currently have time for developing new features that haven't already been developed or training the code base. I think a good software engineer will be able to trace their way around and know what style we go for (pep8, snake_case, no anti-patterns, mypy type annotations, and common sense!) and figure it out. This codebase is not full of pot-holes and unpythonic code tumors and I'm determined that it won't start growing them with new people even if I'm busy. A little problem compounds and grows bigger!

Being a maintainer of an OSS project would be new, but online collaboration is something I have a lot of experience in.

Stay and help or go and develop?

If you wanted to fork and have fun, go for it. Maybe you'll develop some cool things and I'll merge a pull request! If you're willing to deal with a rocky onboarding progress and a OSS community that is just getting off the ground (maybe), you'll be helping all of X-Plane's Blender artists and hopefully having fun getting in on the ground floor of the next chapter of XPlane2Blender.

Above all....

I would love, at the very least, to see this across all forks if the project got more popular:

1. We can work together to define some core data model that stays the same across all forks so people's projects work partially are the same.
2. We continue of have Test Driven Development for anything that calls itself professional enough to call itself a release build. (X-Plane/XPlane2Blender will always strive for 100% unit test coverage, we have templates)
3. Every developer takes extreme care with backwards compatibility or labels the dangers of their version
4. Other forks state that they aren't associated with Laminar Research and .blend files made wit h it aren't supported by the company
5. Good will towards all!

[tngreene]

This bug is too much............ wall of hopeful/hopeless ness. If anything is to be done, it'll be done with hope! (on #594)

[tngreene]

Re-opening so these thoughts don't get lost being pushed way down the bug list. If you have more long form thoughts, please put them here. Just know this is a slow process right now, but, every idea is still read and appreciated!