
Part of that world - ingve
https://www.unroutable.me/blog/2017/4/8/part-of-that-world
======
_jal
Don't ask permission.

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.

~~~
chris_st
> _Don 't ask permission._

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.

~~~
pseudalopex
There are also people who are happy to self-direct but don't want to waste
their time on things that will never be accepted. Some maintainers will sign
off on proposals; others won't review anything that doesn't include a patch.

------
firasd
Interesting reflection. I agree that you can be part of the 'open source
community' without committing code.

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'.

~~~
pseudalopex
I don't think it's anything new. People have talked about the open source
community, the scientific community, the black community, etc. for decades.

~~~
scandox
I think there is a difference in the use of the term Community depending on
who is using it. To some the 'scientific community' is just a term describing
the body of people writing papers, reading papers and attending conferences.
To another it may mean a group of people whose collective scientific
activities and values enrich that individual's life and are a significant part
of their work motivation and emotional satisfaction.

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.

------
hlieberman
Have you looked at all at getting involved in the Debian project?

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.

------
bleezy
It can be difficult for an outsider to contribute to open source projects.
Very large projects don't have simple, easy-to-fix, outstanding issues.
'Outsiders' are generally not aware of smaller projects that would welcome
their contributions. And these smaller projects generally have a very niche
use. For this reason the majority of open source contributions I've made have
been to roguelike games, and generally those that I'm extremely familiar with.

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.

~~~
dom0
> 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.

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.

~~~
nebabyte
Hah, that seems like a terrible idea. Do instructors think there is a
limitless well of trivially-findable bugs that could be correctly fixed by
beginning/intermediate CS students...?

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.

------
nebabyte
The problem of "nonglamorous/thankless work" is easily generalizable to other
fields; it's not new to the field of programming. (Thus, only a fool would
discount this author's thoughts on the basis of her opening with her
perspective disclaimer of 'not being a programmer'.) :)

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.

------
Intermernet
I've only made a few contributions to various open source projects but I think
that I'm an effective advocate for open source in general amongst my friends
and colleagues.

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.

------
77pt77
I think the problem is exactly the opposite.

Not enough focus on code and too many egos involved.

~~~
PakG1
Perhaps the egos are what enable what OP is describing though.

------
uiri
_Every day, every month, every year we prioritize code contributions and
eschew the non-code work that goes towards supporting code, we’re driving away
people who believe in open source, who could be contributing._

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).

~~~
nebabyte
It sounds just as likely that you're in a bubble where it sounds like a
"patently false" notion - It varies heavily by project, and as you check out
smaller (and not necessarily niche, unfortunately!) teams' projects, it
becomes increasingly likely that the ad-hoc'ing/prototyping patterns - that
can indeed eschew 'details' such as testing/docs/maintainability in favor of
'shipping and adding features' \- exist (and can even flourish, depending on
the dev).

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.

------
fredsted
Is there a web portal out there where you can search for and connect with open
source projects needing help in different areas (coding, docs, testing,
design, etc.)?

~~~
jankotek
github?

~~~
fredsted
Sure, the projects are all on GitHub, but how would you find projects needing
help? Just go to GitHub.com, enter "help wanted" in the search field and click
search?

~~~
jankotek
no, i would bet 80% of projects on github need help. just ask.

------
andrewclunn
Great post. I'm a coder, but I find that monetary giving is the most practical
way for me to contribute to projects I use and love.

------
jankotek
But many OS projects are desperate to get help from non-coders. For example:

* 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...

~~~
dom0
> * documentation written by non-native speakers (and lazy/busy devs in
> general) needs a lot of editing and corrections.

ftfy:

> * documentation needs a lot of editing and corrections.

Good docs can be as much work or more as the project itself.

~~~
nebabyte
Except that the former describes useful PRs that could be confidently
contributed by someone who doesn't know the deep technicals of the item being
documented, while the latter could just as easily need such knowledge.

 _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.

~~~
dom0
Can you elaborate? I only removed the qualifier ("written by non-native / lazy
/ busy devs"), since almost any text that has not been copy-edited can be
improved by doing just that, which requires little or no domain knowledge.

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.

------
crikli
I checked out at "I am not yet a programmer." If the author had spent the time
required to write this blog post (and all the others) learning to
code...Shazam, they'd be a programmer. Maybe a few less replays of The Little
Mermaid and a few books from the library on assembly language or even Basic
(don't scoff, that's what I did as an 11 year old in the 80s).

Stop talking about it and start doing it. The resources to do so have never
been more readily available.

~~~
proaralyst
Given you stopped reading at that point, you entirely missed the point of the
article: that open source _is not_ just about code and yet non-code
contributions are undervalued. Perhaps go back to the article and continue
reading before jumping to conclusions.

~~~
crikli
I didn't stop reading, I checked out on her argument.

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.

~~~
nebabyte
> I didn't stop reading, I checked out on her argument.

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.

:)

