offtopic-ish but maybe somebody sees it: can anyone recommend places around the web to look for open source projects where I can help out as a writer? I write and edit professionally but am bad at code beyond some 101-level Java, and beyond that the usual html/css. I've always appreciated well-written help docs, manuals, FAQs, etc of any kind and would like to help out if I can and hopefully learn some things while doing so, even if it's just low-level stuff like proofreading. Can anyone point me in the right direction?
Helping newcomers become contributors to open projects
31–40 of 99 posts
Re: Helping newcomers become contributors to open projects
#32Some practical rules I wish projects would follow, from personal experience: * Have a README. At the top of the README, say what the project does. Document how to build and run it. * Make sure every artifact of the project is buildable from source. This includes project websites and binary releases. Document this process. * Have a clear assignment of responsibilities, and respect it. If you let someone take over a ta…
> Document how to build and run it. This, especially in non-web repos (C/C++) is common mistake of READMEs and docs. Let's take an example of XFCE-WM project [0]. The main README does not include any information how to compile it, nor provides any link to the documentation how to build this very specific code. If you will google it you might find following wiki page [1], which is general for all repositories. In the…
To be fair, that looks like a mirror that’s been separated from its “intended” location (where there might be a link to these instructions) plus it’s a traditional “./configure && make && make install” type project anyways
Re: Helping newcomers become contributors to open projects
#33Open source projects (or any large collaboration) now have a new type of danger that many are unprepared to handle, in that there are people online who will shit on your work or make a giant spectacle that can ruin people just so that they can appear good in Twitter or make some kind of name for themselves in certain online circles. Similar to thieves who steal metal from railways, the damage they cause is far higher…
On the flip side, I have written things that got significantly more attention that I had expected and probably came across to the project maintainers as hating on their work–and that is with multiple drafts to make it clear that this wasn't my intention. There might be random people who like to persecute individuals and their work for no good reason, but even harder to deal with are the people who have been invested…
Bad people cut both ways, and I think it's impossible to design any kind of document (CoC or otherwise) that can force assholes to behave nicely. All these discussions about formalizing relationships, expectations, and behaviors are in my opinion a foolish exercise of programmer logic in social situations, where you abstract away all the difficult human interactions behind something that resembles a function call and then use it everywhere. In reality, all social structures are unique, all relationships take time and effort to build, and a large amount of a programmer's effort will be spent in navigating human structures. The fantasy that you can put up a CoC so you can finally solve the human issues and get back to programming is the ultimate programmer dream, but it's not something that exists in the real world.
Re: Helping newcomers become contributors to open projects
#34Earlier quoted context omitted.
> Don't close bug reports just because they're old. A bug report is either good or bad - that is, the bug is either reproducible or it isn't. A bad bug report is bad from the start; close it quickly - or else, don't close it just because enough time has passed. And don't lock them as stale once closed. Holy shit, it's infuriating seeing projects abuse what is essentially an anti-harrasment tool to prevent people from…
You can learn about a maintainer's experience with closed issues that keep being bumped here: https://www.henryzoo.com/an-issue-with-issues/ Even though I'm maintaining Lock Threads [1], I sometimes shake my head when I come across a closed issue that was locked by it, but I also have to admit that all I want is to ask a question quickly and get the information I need, without considering how my shortcuts affect main…
I get you. I'm a maintainer as well. But I'm not even talking about "long resolved" issues. Last week I saw an issue created by the maintainer themselves to talk about some upcoming milestone or something, that got autolocked before the milestone got there.
Yes, it's just misconfiguration, but when you're configuring these tools you're never thinking about the damage the autolocks do to your project if you're not very careful with the settings. Remember, the people just get turned off from contributing. They don't stick around to give feedback on this being the root cause.
Hell, I never did, and I'm very vocal about autolocking being toxic.
Re: Helping newcomers become contributors to open projects
#35offtopic-ish but maybe somebody sees it: can anyone recommend places around the web to look for open source projects where I can help out as a writer? I write and edit professionally but am bad at code beyond some 101-level Java, and beyond that the usual html/css. I've always appreciated well-written help docs, manuals, FAQs, etc of any kind and would like to help out if I can and hopefully learn some things while d…
I've seen several sites that list open source projects looking for help (see e.g. [1]), but I'm not aware of any focusing specifically on documentation.
My advice would be to look at the documentation for projects that you use or like. The state of documentation in open source projects overall is not great, so probably you can find a project that could use some help. It might take a while to develop a good working relationship with the developers, but once they realize you're a good writer and serious about helping hopefully they'll give you enthusiastic support.
Re: Helping newcomers become contributors to open projects
#36Open source projects (or any large collaboration) now have a new type of danger that many are unprepared to handle, in that there are people online who will shit on your work or make a giant spectacle that can ruin people just so that they can appear good in Twitter or make some kind of name for themselves in certain online circles. Similar to thieves who steal metal from railways, the damage they cause is far higher…
Until recently, having a CoC in the first place is something I viewed as signalling allegiance or submission to the bully crowd you mention. Over the recent years, however, CoC seems to have become a new term for the standard rules boilerplate every community has, so I view it as neutral these days. (Unless someone makes a big deal about adopting Contributor Covenant. That's just genuflecting to the "rail thieves".)
Nope, it's still virtue signalling. By acknowledging the need to have a paragraph of text that boils down to "play nice, or we'll take your things away", you've already given trolls too much legitimacy and power. Why is it so hard to start from a position of: assume all participants want to make the project better from the start until otherwise seen?
Re: Helping newcomers become contributors to open projects
#37Some practical rules I wish projects would follow, from personal experience: * Have a README. At the top of the README, say what the project does. Document how to build and run it. * Make sure every artifact of the project is buildable from source. This includes project websites and binary releases. Document this process. * Have a clear assignment of responsibilities, and respect it. If you let someone take over a ta…
* Don't close bug reports just because they're old. A bug report is either good or bad - that is, the bug is either reproducible or it isn't. A bad bug report is bad from the start; close it quickly - or else, don't close it just because enough time has passed. (This goes doubly for bug reports with advice.)
I disagree... lots of bug reports actually are not bad at all, but are also not something that you want to prioritize. If multiple parties look at a bug report repeatedly for years and do not prioritize it, its a pretty good sign that it is something that will not be done. Closing bugs that aren't going to be done is a good thing, but it isn't always such an obvious decision on day 1. Of course, they can always be reopened (or duplicated) if the situations change.
Re: Helping newcomers become contributors to open projects
#38This is great advice for any organization with a large volunteer community.
Re: Helping newcomers become contributors to open projects
#39offtopic-ish but maybe somebody sees it: can anyone recommend places around the web to look for open source projects where I can help out as a writer? I write and edit professionally but am bad at code beyond some 101-level Java, and beyond that the usual html/css. I've always appreciated well-written help docs, manuals, FAQs, etc of any kind and would like to help out if I can and hopefully learn some things while d…
We need proofreaders at Standard Ebooks! You could even produce a book if you'd like, as the skills needed are basic command line familiarity, and HTML/CSS. Regex is very helpful but not required. https://standardebooks.org
Re: Helping newcomers become contributors to open projects
#40What do you do when the owner of the repository just ignores your pull request? I put hard work into some improvements and I would also change and adapt them to the repository owner's liking, but he just doesn't reply. He doesn't even say he doesn't have time, he's just completely absent. (And yes, the library is very popular and used by many) It's annoying because I depend on that library, so now I have to depend on…
The best thing is to try and find out beforehand whether your pull request will actually get looked at.
It's also not so uncommon for maintainers to just get burned out and disappear for a while, so you might get a reply still.
I made a directory[1] where you can filter projects by things like how long maintainers take to reply, although this isn't too helpful for the specific project in question of course.