mirror of https://github.com/Hypfer/Valetudo.git
145 lines
8.5 KiB
Markdown
145 lines
8.5 KiB
Markdown
# Contributing to Valetudo
|
|
|
|
**Don't**
|
|
|
|
|
|
Heh, I bet you weren't expecting that. But it is actually the answer you're looking for.
|
|
|
|
### Code Contributions
|
|
|
|
Unless explicitly noted otherwise (e.g. in a Help Wanted issue), I'm usually not interested in any contributions to Valetudo.<br/>
|
|
This is because Valetudo is mature software that I'm personally using daily.
|
|
|
|
Due to that, pretty much all low-hanging-fruits are already gone and those that still _appear_ 🍐 to be there are either
|
|
not as trivial and simple as you'd think initially or conscious design decisions that should actually be like that.
|
|
|
|
Everything that _isn't_ a low-hanging-fruit on the other hand usually turns out to be such an invasive change, that I won't be accepting
|
|
any PRs for such changes, because I know from experience that after merging any such PR, I will be rewriting the whole
|
|
thing anyway, which not only doesn't save me any time or effort but actually costs me even more.
|
|
|
|
<br/>
|
|
|
|
Thirdly, Valetudo is not only mature software but specifically mature software that has become **infrastructure**.
|
|
As such, the decision process is different from the one in e.g. a new fun side-project to play around with.
|
|
|
|
There are thousands of people using it. Not every one of them finds reinstalling nixOS/Gentoo/Arch every 72 hours enjoyable.
|
|
Some of them might even have children or elderly to care about. Or they might just also have a life outside of IT.
|
|
|
|
Valetudo thus first and foremost needs to be **dependable**. It needs to work, and it needs to specifically work reliably
|
|
for those main use cases that the majority will have. If there's an issue that affects 3% of users doing something arcane
|
|
which can be fixed by either a large chunk of code or just by not doing that arcane thing, the latter will be the preferred solution.
|
|
|
|
Being **infrastructure** means accepting that covering 80% is good enough if that means less code, less potential bugs and less potential vulnerabilities.
|
|
|
|
Yes, this makes the project super boring. I know, I know. You bought a new Toy, you got root access on it, and now I'm
|
|
telling you that there will be no cool improvements coming from that. Just cloud removal.
|
|
|
|
I know where you're coming from. Don't forget that I'm also a Hacker and I also enjoy playing around with technology.<br/>
|
|
I just _also_ have different hats to wear. Some of them even look kinda funny.
|
|
|
|
Keep on hacking, but.. elsewhere, please. Thank you for understanding.
|
|
|
|
### A word on documentation
|
|
|
|
Documentation is a similar story to what was said above. The docs - for the most part - are how they are supposed to be.
|
|
I know that the project might not be immediately accessible to _everyone_ without further research but that filtering is a feature and not an oversight.
|
|
|
|
I do quite enjoy writing documentation, so I generally don't need help in doing so. In fact, I think it's best if I do it,
|
|
because I know quite exactly how the software works.<br/>
|
|
Playing a game of telephone will already happen further down the information chain.
|
|
It shouldn't be part of the documentation itself.
|
|
|
|
The docs are the single source of truth, so they need to be truthy.
|
|
|
|
### Some context
|
|
|
|
Because I *support* newcomers and long-time-users *daily*, I pretty much know _exactly_ where the pain-points are,
|
|
what issues there might be, which things people struggle with and what the scope should be. Therefore, it is highly
|
|
unlikely that someone new to the project happens to see something obvious that all people just missed until they came along.
|
|
|
|
It might happen of course, but the chances of having another nonsense discussion are a few orders of magnitude higher.
|
|
|
|
I also have developed a quite good understanding of who this project is for and - more importantly - who it isn't for.
|
|
I can tell who will struggle with it, what drama that will cause and if it is worth it. The docs take that into account
|
|
and try to filter to avoid all this very exhausting drama.
|
|
|
|
### On (not) growing the target audience
|
|
|
|
Please keep those filters as-is. Please do not invite people that clearly can't pass those filters to the project.<br/>
|
|
Please do not attempt to "make things more accessible". Please do not make any video-tutorials.
|
|
|
|
It's not helping anyone, because at the end of the day, it will still be yours truly that has to deal with the support requests resulting from that.
|
|
Not only are my capacities limited but they also can't easily be scaled up by just throwing more resources at the problem.
|
|
|
|
While it is true that "the community" can sometimes in some cases take over some of that load, a look at other projects
|
|
in the real world shows that this usually comes with a heavy penalty on quality and sanity.
|
|
|
|
The fact of the matter is that sustainable growth is slow, boring, iterative and usually doesn't provide any dopamine hits.
|
|
|
|
**Side-note:**<br/>
|
|
|
|
Half-baked "I'd like to do good" **always** just backfires and **only** increases the workload on the existing volunteer structures.<br/>
|
|
That is no FOSS-specific or even software- or IT-specific issue. It affects any "social" project/movement/idea.
|
|
|
|
Yes, short-term, numbers may go up and there may be some benefits, but there is no free lunch. These short-term gains
|
|
have to be paid back long-term and they have to be paid back with interest.<br/>
|
|
The problem is that often, projects then can't pay that interest and so they default.
|
|
|
|
You often have (well-meaning) third-parties that enter a project, make number go up, push the thing into long-term unsustainability
|
|
and then leave with the proud feeling of having done "the right thing", never to be seen again to be held accountable
|
|
once things start to fall apart later in direct consequence of their actions.
|
|
|
|
If you've ever seen a large corporation from the inside, this may sound familiar.
|
|
|
|
What I find fascinating about this is that the exact same thing not only keeps happening in "social" projects but also
|
|
that it is being done by people that often have strong opinions against the business world. Go figure.
|
|
|
|
|
|
### Being for everyone
|
|
|
|
> A friend to all is a friend to none
|
|
>
|
|
> ― Taylor Swift
|
|
|
|
|
|
If there's one thing to take away from this text then it's that the opposite of _"not for everyone"_ isn't _"for everyone"_
|
|
but rather _"for no one"_, because things trying to be _"for everyone"_ will always collapse under their own weight.
|
|
|
|
<br/>
|
|
|
|
Please also note the **important distinction** between _"for anyone"_ and _"for everyone"_.<br/>
|
|
Valetudo actually is _"for anyone"_, because anyone can pick it up; no matter the specific selection of attributes such as
|
|
e.g., sex, gender, age, ethnicity and whatever other uncontrollable backgrounds you can come up with.
|
|
|
|
It is however not _"for everyone"_, because _"everyone"_ is a superset of _"anyone"_ that then includes wants, needs,
|
|
ideas, behaviour and whatnot.<br/>
|
|
Basically everything the individual _can_ and _does_ control.
|
|
|
|
It is true that controlling those things can sometimes be more challenging depending on background, but we're talking
|
|
about a cloud replacement for vacuum robots (read: luxury goods) maintained as a hobby project by some random guy on the internet.
|
|
|
|
Expectations need to be reasonable.
|
|
|
|
### Expectation management
|
|
|
|
On that note, to set expectations, you can basically think of Valetudo as **freeware with source available**, so that
|
|
others can learn from it, and you can be sure that I'm not doing something evil on your robot.
|
|
|
|
If you base the way you'd like to contribute something on that mental image, it's probably correct-ish.
|
|
|
|
### Final remarks
|
|
|
|
I do want to point out that not only do I generally enjoy the exchange with other people regarding
|
|
ideas, feedback, etc., but also that Valetudo wouldn't be where it is today without the many contributions; be it as code
|
|
or as ideas or as feedback or just as listening and being present in the community.
|
|
|
|
I think the key takeaway from this page should be that generally, contribution is welcome, but the way useful contributions
|
|
manifest for this project in this stage doesn't involve actively looking to contribute.
|
|
|
|
There was a time in the Valetudo lifecycle where it was different. For example, the Logo came to existence because a person
|
|
was actively looking to contribute to open-source projects with no focus on Valetudo in particular. And at the time that was absolutely fantastic.
|
|
It was exactly what the project needed and looking back you can really see how "just" having a proper logo made Valetudo a lot more "real".
|
|
|
|
But as said, Valetudo is now in a different situation with different wants and needs. Fear not however if you just want to
|
|
contribute to something cool and FOSS because there are a ton of cool FOSS projects out there that would love to see your contributions :)
|