how to build a community

[lshems]

Hi guys,

I love to work on making things work. I hate it when I don't have the tools to do it, or the knowledge to use the tools.

3D printing: I would love to print a small cockpit/wing connector for my 70 cm DLG, but I don't know how to use a CAD program. Lots of people offer me to print for me, but I still have to come up with the printable design. So, no go until I figure out how it works.

Learning Arabic: without being able to speak it, so without having a relevant vocabulary present, and Arabic being written in another script on top of that, very little useful resources to learn it on your own. On top of that, vowels are not written in Arab, so tell me what is written here in English without you knowing the words and thus the vowels: "th qn s ln nw snc hr hsbnd dd": "The queen is alone now since her husband died". Try to figure that out!
Then, if you can't read about something, you can practically not learn about it. So, no go until I speak it a little better.

All fine.

But here we have a community of smart programmers, blowing new energy in a previously dying concept. That enthousiasme creates a momentum, and attracts a lot of people who would love to help and be part of that energy.
Alas, most of them are blocked for reasons as sketched above. They lack the tools or the knowledge about the tooling to be able to help.

I am spending several hours each week on LUA scripts, since they are fun and understandable for me, without any complex tooling. Sure, tooling helps, zerobrane, ..., but lua scripts as such are not full of syntactic sugar, and are pretty BASIC to create (pun intended).
But I'm getting frustrated because I want to help, but I cannot help. It is simply not useful to be able to test things like lua scripts only on a physical radio.
And I've already given up times ago, after spending days to figure out how things work, to try to understand the C code and alter things to make them work. Let alone being able to compile the code to test my changes.

The point I want to make is that if you don't want to loose the manpower available from people who are starting to move again around this EdgeTX project, you need to cater fort heir needs. Care for them. Nourish them. Make life easy.

I would love to see a real community, with effort being put in from several sides, including myself. Not only programming and coding, but also conceptual discussions like what is the best SDcard structure for future maintainability, how would we want un update to work, where can we improve the GUI, things like that. I bet that the not tech-savvy people can tell you much better what can be improved in the update process than programmers creating the update process.

If I tell you that 90% of all the customers I have for my scripts are afraid to update anything on their radio in order not to break it, because they don't know how to properly backup anything, and have no trust in doing that themselves? Isn't that a pity?

So, please, tell me IF and how you want to support a community of users that create content (models, bitmaps, themes, apps, scripts, sounds, voices). And where these people can find the resources that they can use to do just that?

And with resources I mean firmware they can test, updates that are easy, instructions that are clear.

I know, that may not seem a priority in the heat of getting a release out. But I'm afraid that if you don't pay attention to the not tech savvy users, and make sure that they ALSO can contribute, this initiative will soon again be a dying initiative.

[lshems]

Oh, and before I forget: Can't we make finance a transparant issue? Money makes the world go around, even in hobby projects.

I would love to spend money if that motivates programmers to participate, other people to help, servers to be set up, hardware to be provided for testing.
Really, this is a hobby, and I'm not looking for return on investment here. I'm looking for fun things, to do with fun people. And if that means I have to help finance a server so that things can be done, i'm the first to do so.
But NOT when the financial structure and in and outs of the budget are not clear. I don't want to spend money on things I can't see. And it is not a crime to make a clear statement on what will happen with donations.

So if you create a transparent budget, and transparant rules on how to manage rewards for effort, I think people are much more tempted to contribute financially. More than when there is this vague notion of "not having profit as objective" around the donations you make to certain organisations.

I could be perfectly happy with a statement like 25% of donations are spend on infrastructure, 25% of donations is spend on hardware for developers, and 50% of donations is shared among the top 5 contributors to the base code.
Just an example of course.

A lot of text written in the I form, but please don't understand me wrongly. I think I speak for more people.

So let's discuss and see where it ends.

[raphaelcoeffic]

Having full transparency on finance is definitely something that is important to me as well! It think everyone deserves it.

[pfeerick]

Derp... I meant to mention that also... that I know financial transparency is high on the list ;)

[pfeerick]

Documentation is going to have to be one big change EdgeTX brings, as OTX has become more than a joke. The OTX 'manual' is for still for 2.3 - there is no documentation for 2.3. And even then, the 2.2 stuff is/was Taranis centric. This is what OTX themselves said re documentation for 2.3.x:

The manual has not yet updated to include all Horus documentation/OpenTX 2.3 changes, so get yourself a good coffee to wake up, and refer to the the great communities for help e.g. openrcforums here, RCGroups and threads like this one. You can pop in our chat room where other users and/or devs may be available.

In my view, that is completely unacceptable. Whilst the development of 2.3.x was ongoing, there should have been work on companion documentation of some description, otherwise the temptation is to just release it without no documentation, because it will be a gigantic effort at the end to write it. I can understand it being incomplete, not as detailed, need improving, but non-existant... and refering people onto the various forums for what should be included already? Not a good start. And I currently see no reason that OTX 2.4 won't go the same way, given that OTX 2.3 is probably getting near to end of cycle, and there is still no manual or official documentation for it... I know more than few people that said they wanted to use try OTX, and then said blow this, they'll stick with the stock firmware that came on their transmitter because at least it was documented.

We're gradually starting to get the first parts of this done, thanks to the great work by @rotorman on the build guides on the wiki. I haven't spoken to @raphaelcoeffic about this yet (as I'm only just starting to think about this now), but I think we could use Github pages to start building a documentation site - with links to build instructions, start building a manual of how to use EdgeTX, lua guides, useful videos etc. Start making it so people have somewhere to go to answer that question that's been asked 1000 times already ;) We could enable it on this repo, in it's own branch, but since an organisation has been setup, it is probably better for it to have it's own repo, so that it can have it's own issues and pull requests, and keep the source code repo uncluttered.

[lshems]

Can I suggest something: make a build-test-document team for all pull requests. This would allow the builder to hand over stuff to a tester and a documenter, that do not necessarily need to have coding capabilities.

We would need to find a way to organise this, but I for one would be happy to help and test, or document.

Using the chat on Discord might be a way to do the alignment between the teams for an upcoming pull request.

?

[raphaelcoeffic]

These are the processes as done at my company 😋 Not sure we will manage this, but we can try.

[pfeerick]

Having a channel on Discord restricted to the core team would be one avenue... meaning the #dev room on discord is more general development chat, rather than the 'day to day management of the project' side of things. I think it's then a matter of deciding who is going to focus on what, and then things like assigning issues, assigning reviewers of PRs can start to fill in the rest.

i.e. I did a PR to do with the companion, was happy with it locally, so assigned rotorman as a reviewer as I know he's been doing all the build tests so it if passed his review it was ready to merge.

[JimB40]

TL;DR so is that proposal to contribute doc creation (like 2.4.0 FAQ is most needed). ???

[pfeerick]

I think so... i.e. https://github.com/EdgeTX/edgetx/wiki/Workflow-for-GitHub-noobs exists now (nicely done btw!), and some else has done a much needed update to the README with links to documentation ;)

[phileville]

@lshems I agree with you on this. I think that we should harness the buzz about EdgeTX right now to recruit as much help as we can - especially with the non-development tasks like documentation and testing. I think that there are many people that would be willing to help, they just need to know how.

Like it was mentioned earlier, I think that we need to get the documentation in order so that the new features are docuemented and users know how to use them We can be lazy and wait for the Youtubers to make videos, but who knows if they get it right either.
The more we document, the less repetitive questions devs have to answer on discord.

Also, I think that it would be good to come up with a sort of test plan / guide so that volunteers can do overall system testing with some sort of guidance.

What I would propose, is that we start making issue tickets for topics that need to be documented and then once we have a good healthly list of topics, we can rally the troops to get people to help writing the documentation.

If we dont want the main issue board for the development spammed with all the issues, we can use the edgetx.github.io repo issues board for that - since most of those topics will be on the main webpage eventually anyway, and are geared more towards users and not so much for developers.. Also, I would propose to keep the user focused How-tos on the edgetx.github.io repo and the developer how-to's on their respective repos... (like they are now)..

[phileville]

Also, in regards to docuementing new features, I think that it should be kinda Automtic - Everytime a new feature is developed, a ticket is made for documenting the new feature and someone explains in laymans terms how it works and how to use it. If the PRs have enough info, then this should not be that hard of a task.

[JimB40]

Definetely issues abt docs on edgetx.github.io
FAQ for 2.4.0 is most urgent. Every day on #general same questions
To name few

• is my radio covered? (Is NV14 covered)
• how to install EdgeTX and go back to OpenTX if I don't like?
• where is SD card content?
• is there Companion integration?

Some of answers are so easy as including one sentence and pointing to YT movie.

[lshems]

Make a place where we can start

[phileville]

https://github.com/EdgeTX/edgetx.github.io/wiki
That is where we will put the docuementation for geared toward everyday users. I have already created the FAQ, Installation guide, community guidelines there. Check if you hae edit permissions already..
https://github.com/EdgeTX/edgetx.github.io/issues
here is where we will create and track the documentation and website to-do tasks

[phileville]

The website will eventually need a bit of a modernization update - but for now I think docuementation of some key things is more important IMHO

[jrwieland]

just a thought, what about going back to google docs for the documentation (initial write-up) all collaborations are presented IRT and automatically saved to a single document. OTX started with this format back in 2012 but they exceeded the server capacity and moved to github. Once the initial write-ups are complete the file can be transferred to the wiki or saved in any format that could be accessible via web or download.

my 2 cents, but I am here to get the documentation online... like everyone else.
also, we could also ask for another tab under discord development for conversations on this subject since it will have man questions and the need for communication between the writers.

[phileville]

I like that idea, I already have a google account for EdgeTX that we can use for the google docs. (I initially had the installation guide there). Also, creating a documentation channel makes sense as well.. I will request one.

[jrwieland]

send me a link to the document when you get it up
[email protected]
so I can work on it

[lshems]

Just a reminder.

I have spent serious time on setting up a compile environment on an Ubuntu wsl in Windows. Also read about GitHub and how to use that. This worked to get a firmware, simulator and companion for Ubuntu compiled to at least be able to check some of my lua scripts.
I wrote a tutorial on how to do that.

Now I'm lost again, as it doesn't work anymore.

My issue is that I cannot spent 10 hours of trial and error to get something compiled, test and fix things for one or two hours on lua, and then have to go to ten hours of trial and error again to get the next fix or PR request compiled on my pc.

This limits the usefulness of the current efforts, as only a few are able to do some Liz development, whereas this lua thing with touch IS the biggest game changer for EDGETX and that can make it super succesfull.

So, although it may sound like me whining for help, which is partly true, it is also a cry out to decide what and what not to do to overcome this issue.

In my opinion, the things which are needed are:

A compiled companion for Windows available for download, both for the current version as for the nightlife
A compiled simulator (standalone or as part of the companion) for at least a colour, BW and gray-scale radio.
A compiled firmware for at least a X9D, an XLITE, and a touch colour radio (as most LUA adepts will have one of those three laying around).

So please let us know if:
There are plans to facilitate the community with these precompiled software on nightlies.
Are there plans to go even further than that (compile of every PR to test, for instance)
There are no such plans.

Thanks for the clarity.

P.s. not that it may bother anyone, but I'm not spending time in a ten on one ratio for setup/compile versus testing/lua dev anymore.

[pfeerick]

To answer your question about companion and simulator, you will be glad to know that the work on it over the past month is coming to an end... #555

And if you give a bit more info as to "it does not work", we can probably fix your problem... It's probably something simple like needed to do a submodule update in a particular way because git is annoying that way.

[lshems]

Thanks for the update.

As far as your enquiry on more info on what doesn't work. It's like asking my wife why the car stopped. She will just say 'because'. If I start asking more questions, it won't help. To be able to understand what doesn't work, you should first understand how it should work.

So I really appreciate all the work, really.

And I'll just wait for stuff to be released for users befoe I will get back to doing an update on my lua scripts or developing for the framework Jesper and Robert are started with.

It just isn't worth the effort right now.not much that can be done about that really, I think.

So don't get me wrong, I'm not blaming anyone. I found the edgeTX dev attitude very refreshing and open, and I'm sure that if you keep up with the userability focus, we are in for some nice surprises.

Greetings.

Guido

[pfeerick]

No, not quite... at least she would say some light blinked and give you some clue :-P

Any chance you could share the error message you are getting, so I don't need to get my mind reading cap on? 😆 The only things I know of that could cause breakage of late "just" need the submodules updated properly, or perhaps the docker container updated... if there is something else we need to know what is going on so we can either fix or document a resolution!

[lshems]

My wife doesn't know there are dashboard lights indicating issues.she doesn't know the word dashboard.

But you are mindreading already, because I don't use docker. I got as far as understanding how to get ubuntu to run and get it to compile something using a pull from GitHub to get some files to be compiled.

If you follow the steps from the instruction I published on the wiki (workflow for noobs) you should get the same errors. Lots of compile errors and just not finishing the compile.

[pfeerick]

she doesn't know the word dashboard.

My commiserations... you really are in pickle there... but at least you won't get the "honey, the car wont start... and all these blinking lights are showing up... what could be the problem?" question! 😆

But you are mindreading already

Not quite... I simply mentioned the two changes recently that may trip some people.

If you follow the steps from the instruction I published on the wiki

Not necessarily... if I start afresh (whereas you had a working system)... issues like submodule updates won't be a problem. I have basically followed that guide, and I have both firmware and simulator compilation working on WSL2. There are a couple of things you need to take into consideration if just trying to follow the Ubuntu install instructions on WSL2, as they won't just work on WSL2... for instance, you need to ensure you are on the WSL2 virtual drive otherwise you will have permissions problems. And the last step of the build preparation is to restart your system, so that your path is updated... which you can instead do via source ~/.bashrc ... otherwise you'll get a nice error like this if you check the cmake output before running the build... (if you do try to compile... boy, you'll get a lot of nice errors!).