How To Get Involved?

JoshStrobl

Open question to the team ( @Ikey, @ermo, @sunnyflunk), how does one get involved in the development and community of SerpentOS (yes, I see the irony of asking that in a community space). I pose this question since SerpentOS is still in the early days, pre-GA, and so shaping the community and core values, as well as making sure there are clear pathways for involvement, is crucial to a strong start and the ability to build momentum.

Non-Technical Users

Given SerpentOS is being rapidly iterated on and is not yet in a state of GA, this is arguably one of the hardest things to address at the moment. Right now the best ways are the OpenCollective financial support and engaging across the forums (yay, those now exist woohoo) and Matrix (yay, no IRC), at least in my opinion.

Non-technical users may be multi-lingual. What focus will be put into ensuring content, such as documentation, can be in a translatable state and reduce the maintenance barrier? Some examples:

Documentation Center articles and site content should be translatable when / where possible. This is typically done nowadays outside of translation tools like Transifex and Weblate, and rather just creating a locale-specific Markdown file for the translated doc, use some form of a JSON file for transaction key / values (this is how Docusaurus does it anyways).

If a user is not multi-lingual (or does not feel their language skills are sufficient to contribute in that manner), what ways would you like to see engagement. This can be now or post-GA. Are there unique or interesting pathways for us to transform those "non-technical users" into "technical users", leveraging the wealth of resources such as existing language references, doing packaging livestreams, etc.?

Technical Users

Some questions related to technical involvement:

What are the current best ways for technical users to get involved? What language skills are needed and what would you say are the best resources for learning them?
What is the status of running SerpentOS in an isolated environment?
What is the current status of packaging within SerpentOS? If there are any blockers for contributing packaging files, what are those? (I know Summit and the build infra is one of the biggest ones, but is that the sole blocker?)
Post-GA what are the expected largest hurdles to growing the userbase that technical users can help to overcome?

Ikey

Thanks for the post, JoshStrobl !

So right now it's arguable we're in major flux and the method of contribution is largely unknown - which is usually considered a bad thing. On the other hand - I consider this a good thing as it allows us to actually define it now.

Our intent is to move everything to GitHub to PRs. Regarding documentation - ideally I would've liked it integrated into the main website but as you say, it needs to be translatable. The current iteration of the website is going to be "just enough" to allow a switch away from Hugo while importing all the original Hugo content.

I believe we'll want translations stored into a DB, likely using a gettext model, and have the frontend fetch the right language.

JoshStrobl If a user is not multi-lingual (or does not feel their language skills are sufficient to contribute in that manner), what ways would you like to see engagement

Honestly at this point - involving one self in in the feedback loop. Tighter communications. The priority at this minute is to get us to a point where initial packaging is possible for all contributors, so we can fix any early format/process issues.

JoshStrobl What are the current best ways for technical users to get involved? What language skills are needed and what would you say are the best resources for learning them?

For the low level bits? Dlang - might be worth checking the D playground or our repos for inspiration.

Higher up? Be creative and diversify!

JoshStrobl What is the status of running SerpentOS in an isolated environment?

This has actually worked for a long time we just don't do it as we're more interested in the infra. You can "run" Serpent OS chroots and namespaces they're just not entirely awesome.. 🙂

JoshStrobl What is the current status of packaging within SerpentOS? If there are any blockers for contributing packaging files, what are those? (I know Summit and the build infra is one of the biggest ones, but is that the sole blocker?)

Basically just the infra and shift to GitHub. Tis all 😁

JoshStrobl Post-GA what are the expected largest hurdles to growing the userbase that technical users can help to overcome?

Documentation, translations, robustifying the code and extensive testing, hardware enabling..etc =) (Also, packaging the stuff we NEED)

ermo

What are the current best ways for technical users to get involved? What language skills are needed and what would you say are the best resources for learning them?

Core tooling is Dlang, YAML + POSIX sh (quicker start up times for ./configure runs with dash) with a bit of bash for surrounding stuff by choice and design.

A good way to start learning Dlang is to visit https://tour.dlang.org/

The core tooling employs a variety of fairly advanced Dlang tricks such as Compile Time Function Execution, source code generation at compile time via mixins, lots and lots of templates and a mostly functional style w/structs for algorithmic clarity. Certain functionality is wrapped in a relatively shallow OOP layer focusing on composition rather than inheritance.

Many of the concepts listed are introduced in "D's Gems" in the site above.

As an aside, note that Dlang is currently experiencing quite a bit of growth and churn, mostly related to correctness, cleanup and memory safety. This implies that we tend to use the newest available LDC compiler as that allows us to immediately reap the benefits of this work.

Other than that, hang out in the Serpent OS matrix space and begin looking at the code.

I have done my best to attempt to break our Roadmap up into bite-sized chunks with tasks and checkboxes, but as it stands, the core tooling design is still in enough flux that it will be a while before it's easy to contribute code directly via MRs/PRs I'm afraid.

So that's something that we will need to look at once we've hit our first milestone target.

In terms of getting started with compiling the current code base, I have created an onboarding process that I try my best to keep in working order. YMMV.