Post Aj01MCmJSGPJCw9WQS by matthew@social.fennell.dev
 (DIR) More posts by matthew@social.fennell.dev
 (DIR) Post #Aj01LqFFEWsrK0VnpQ by matthew@social.fennell.dev
       2024-06-16T21:10:44Z
       
       0 likes, 0 repeats
       
       This thread contains some things I've learned (some through observation, and some the hard way!) when contributing to #FreeSoftware projects.A lot of it seems like common sense / second nature to me now, but it wasn't always when getting started.Of course, nothing here is a hard or fast rule, and it might not apply to every project. Wherever I say "you" below, I really mean "past and/or future me!" Anyway, here goes.
       
 (DIR) Post #Aj01LrHPNyD0X0X2q8 by matthew@social.fennell.dev
       2024-06-16T21:11:00Z
       
       0 likes, 1 repeats
       
       Go out of your way to have a positive tone, in all interactions. First and foremost, the goal is to have fun.
       
 (DIR) Post #Aj01LwE2ztUVs1zvnM by matthew@social.fennell.dev
       2024-06-16T21:11:14Z
       
       0 likes, 0 repeats
       
       Start with very small issues, so you can get a feel for what's expected without too much at stake.
       
 (DIR) Post #Aj01LyHfLPZeFphqiG by matthew@social.fennell.dev
       2024-06-16T21:11:25Z
       
       0 likes, 0 repeats
       
       For your first few issues in a project, once you've worked out what you'd like to pick up (and are pretty confident you can fix it), announce you're planning to work on it, with a rough high-level description of your plans and any questions.
       
 (DIR) Post #Aj01M0lA8iMBvtWQy0 by matthew@social.fennell.dev
       2024-06-16T21:11:44Z
       
       0 likes, 0 repeats
       
       Don't give unsolicited advice about any part of the project - be it code style, releases, builds, tests, etc, apart from precise bug reports or feature requests. If you think the code should be written one way, but the maintainers want another, go with their approach (and live to fight another day!)All of that can come in the future, if you have more of a role in the project, or if it is explicitly asked for. Very often, you'd end up thinking differently if you had the whole picture / context!
       
 (DIR) Post #Aj01M3JcdZ6rrLeyxM by matthew@social.fennell.dev
       2024-06-16T21:11:53Z
       
       0 likes, 0 repeats
       
       Don't stress too much if you disagree with a decision. In the long term, if enough people think something is important, it will happen one way or another.
       
 (DIR) Post #Aj01M5XsLXhQm8LOS0 by matthew@social.fennell.dev
       2024-06-16T21:12:01Z
       
       0 likes, 0 repeats
       
       Whenever you raise an issue or PR, start a 3-6 month timer (depending on the project). Wait at least this time before bumping the thread, or following up in some other channel. If the fix is good, often, other people will bump the thread on your behalf. Whenever they do, reset the timer.
       
 (DIR) Post #Aj01M82n3ZcIWap6um by matthew@social.fennell.dev
       2024-06-16T21:12:09Z
       
       0 likes, 0 repeats
       
       If an issue affects you and you want to get it merged - fix it for yourself first, and be prepared to maintain a private fork. Then, it takes the pressure off getting it merged quickly.
       
 (DIR) Post #Aj01MAbFYQMyS2xeu8 by matthew@social.fennell.dev
       2024-06-16T21:12:19Z
       
       0 likes, 0 repeats
       
       If you disagree with the maintainer on something, once you've made your point once, show you've accepted their decision, and move on. If you really need a feature some way they don't like, do it on a private fork.
       
 (DIR) Post #Aj01MCmJSGPJCw9WQS by matthew@social.fennell.dev
       2024-06-16T21:12:33Z
       
       0 likes, 0 repeats
       
       If there's anything a maintainer explicitly wants you to work on, really consider working on it!