Part of that world
unroutable.me
unroutable.me
If you see something that needs a better design or documentation or whatever, make it. Put the docs up on your own site, find someone to help you do a demo-graft of your UI on to whatever it is, etc.
Worst case is $in_group doesn't use it. Docs might help someone else, your UI can be a case study in your belt. Or maybe folks want various changes, and you work through that.
Just keep in mind that functional projects and communities generally have most of the stuff essentials for immediate continuance sorted, otherwise they wouldn't exist, and they all have some surface tension, otherwise they wouldn't be distinguishable from everything else.
Also, because they're made of humans, they're rife with hierarchies, official and otherwise, and they're full of all the other bullshit people get up to. And a lot of what is bemoaned in that essay applies to any group made of talking meatbags.
I'd go a bit further... I'm a programmer, but I've done several contributions to projects where I just corrected the grammar of the README (which, I imagine, some folks would think kind of rude, but I think it helps).
Every contribution was accepted, and I think I was even thanked once!
Also, I've seen, both at my full-time day job and on open source projects that there are some people who feel that they need to be told, explicitly, what to work on, and some who just dive in and start on something.
I think that the author of this article fits, to an extent, in the first category; sometimes, those people ask for something, and are told (occasionally, alas, brusquely) "Don't bother me, get something done!"
Perhaps we need to figure out how to build a bridge to these people... without giving the impression to the "dive in" crowd that they will have to be full-time hand-holders of someone.
As an aside, this discourse of 'community' that has been developing over the last few years has never sat perfectly well for me. Can an activity in which tens of thousands of people worldwide participate ever really be a singular 'Community?' Communities are great in many ways, but there is a creepiness to such semantics too, such as enforced commonality of values or behavior. Can you be a skateboarder without being part of The Skateboarding Community? Maybe we need to talk about 'cultures' or 'subcultures' in tech, not just 'communities'.
The open source community exists in the same way as (and partially overlaps) the scientific community.
- A community can also refer to a diverse set of individuals who happen to have something in common. I'm a part of my local community, even though god knows there are people here who are unlike me, and/or whose values or behavior might differ from my own.
I think there is a natural friction between those two views. Some people are solely motivated by their work and view other aspects of community as a bothersome necessity, or at best a source of a few collegial laughs. To others the work and the wider communal epiphenomenon are deeply intertwined: they would likely not sustain interest in the work without it.
I think both views have their merits- but they don't mix well.
I would say it's a bit oversold, and of course (where it exists) community has drawbacks too, such as the inevitable hierarchies, conformity and gatekeeping. And individuals usually have to give more than they get in return, to make a community work. But they are the only way to get shit done!
Previously, there was an incredible focus on developers who contributed by packaging -- to the point that voting membership required you to demonstrate your ability and involvement in packaging.
Debian realized that was excluding an entire category of contributors, many of whom were incredibly dedicated, and created an equal path to becoming a Debian developer for people who aren't engaged in packaging work at all.
We are always looking for help in countless different places; if you want to be involved, please consider reaching out to the Debian newcomers team. If a personal introduction will help you feel more comfortable, email me at <my hn username>@debian.org and I'm happy to help get you involved.
To be honest, a PR from someone who doesn't use your software, who is unfamiliar with its structure and only wants her PR merged so that she can say 'I am an open source contributor' is a hassle.
I also think it's unfortunate that the author thinks her feelings might be due to impostor syndrome, when she is quite clearly an impostor to some degree.
My best advice would be to stop looking for a repository to contribute to. Just keep using software that you find helpful, and eventually you will find yourself using a small library with some missing features that you can add. Or, just host all of the software you write on GitHub. Create nice readmes. Create issues and releases. Talk about your project in a forum of likely users. Maybe someone will contribute to your code. Boom. Now you are part of the open source community.
This is a reason why mandatory open source contributions (yes, that's part of some curriculae nowadays) are a double-edged sword. On the one hand, some of these go on and do valuable work, others just want to invest the absolute minimum effort to pass the class.
I suppose if the instructor is running the project that's a different story - just upload a buggy-as-hell project with fixes you expect students to be capable of - and preclude unleashing your class on the community at large until you can (patiently and didactically, because you know them to be beginners to VCS) show them the ropes on something harmless...
Of course, I'm sure that's not the case everywhere, and god help those who have to deal with that.
This isn't generally true.
Large and well-established open source projects usually have dedicated schemes to match new contributors with simple tasks.
For example, here is the GNOME program which gets you started with some hand-picked, newcomer-friendly tasks:
https://wiki.gnome.org/Newcomers/SolveProject
Similarly, LibreOffice has the "Easy Hacks" project:
As to the problem, though - it's certainly not an easy one to solve, and not made any easier by the general need for QA/expertise to be attracted to that 'thankless job'. I personally believe that better tooling or processing is what's missing from the equation - an expert can (and does!) often try and relay elements of that pseudo-work to colleagues or themselves (in notes), but when it comes time to formalize into documentation, the 'joy' of thinking through the problem is instead replaced with the ardor of 'cleaning up and standardizing' one's thought process to meet a format.
On the other hand, process models more readily welcoming of a few 'non-code-monkey monkeys' around to handle the useful-but-overlooked work there might be an answer too.
One task that is often neglected, by myself as well as others, is documentation review. I'd like to suggest that anyone wanting to make contributions to open source software, and has the time and knowledge to do so, please expand and correct the documentation for any favourite projects that seem like they need it.
I have a feeling that good documentation is more important than good implementation when it comes to product adoption.
I'm going to try to follow my own advice here. There are a few projects I use that could really do with better docs, and I think that teaching people to use software correctly is easily as valid as fixing bugs or adding features.
Not enough focus on code and too many egos involved.
The claim that documentation and testing are eschewed is patently false. Every software professional is well aware of their importance and when there is a related deficiency in one of their projects. Documenters, code reviewers, testers, and security folk need to know the codebase as well as anyone in order to properly document/test/review/pentest the code. While it is nice that artists, managers, organizers, and fundraisers want to get involved, they are not always relevant to smaller open source projects (which tends to be most of them).
I don't mean to minimize the experiences of the author, but perhaps she would do better to perform a security audit of her favourite project than to write a blog post about how she feels marginalized (not that the two are mutually exclusive, of course).
While fortunately as these projects grow the 'rest' of a process model is introduced by others in the community, it's certainly lacking enough to the degree that calling it 'patently false' would be at all accurate.
https://www.gnome.org/get-involved/
https://www.libreoffice.org/community/get-involved/
* documentation written by non-native speakers (and lazy/busy devs in general) needs a lot of editing and corrections.
* complete artwork (logos, inverse logos, web template, slides...)
* sorting and answering bug reports. About 70% of bugs opened on Github are just simple questions
* project management, release schedule, maintaining work queue...
ftfy:
> * documentation needs a lot of editing and corrections.
Good docs can be as much work or more as the project itself.
Bad docs can be just as much an impediment to useful work as bad PRs to the project itself. Someone not confident in submitting a code PR might similarly not wish to try and 'clarify' something they don't actually understand.
Also don't undervalue documentation feedback. Everyone makes first contact with a project only once, and the feedback of this "onboarding" can be invaluable and point to critical shortcomings of documentation.
Stop talking about it and start doing it. The resources to do so have never been more readily available.
What the author was saying was compelling up to the point she admitted she couldn't code.
Non-code contributions have value, however if you don't have the engineering understanding to grasp the full context of a project your perspective likely isn't going to be taken seriously.
With all of the resources available now to learn to code, I just don't have any sympathy for her. At all. She doesn't need to be contributing to every project in order to have an opinion worth considering, she just needs to be able to demonstrate some level of development chops.
Then if you had spent the time required to belittle the author on lack of coding ability to address the very valid commentary provided on communal work... Shazam, you'd have gotten your point across to proaralyst. Maybe a few less condescending chidings and nostalgic recountings of 'your youth in the 80s' and a few quotations to counterargue (don't scoff, that's what many people do in discussion)?
Stop talking about 'checking out' of useful discourse and start having it. The resources to do so have never been more readily available.
:)
Comments that lead with "I immediately stopped reading" are puzzling. If you could not sit through someone else's opinion long enough to get to their actual point, that's fine - but then you turn around and expect others to humor your recounting of that experience rather than the thread topic and read commentary that necessarily won't have anything to do with the main topic?
For that matter, why would other thread readers want to read a opinion self-declared as ignorant of the whole topic, which is likely to miss out on key points? It certainly does in this case - the author raises a valid concern within the OSS environment of the lack of incentive for 'useful nonglamorous' grunt work, yet your comment instead waxes nostalgia for your days as an 11 year old.
Discounting another's opinion simply at the point that their experiences and perspective diverges from your own (and those you consider acceptable) is practically one of the cardinal sins of open and rational thought and discussion. Frankly, I'm surprised you're flaunting it so proudly and openly.