Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
Matthew's list is pretty good, although I don't think one has to do all the things on it as a "minimum." I offer one minimum and a couple nice-to-haves. Some of these I have learned as a contributo...
Answer
#4: Post edited
by
Michael
·
2024-05-20T13:50:19Z (6 months ago)
Tone down some language. Subheadings rather than list items.
- [Matthew's list][matthew] is pretty good, although I don't think one has to do _all_ the things on it as a "minimum." I offer one minimum and a couple nice-to-haves. Some of these I have learned as a contributor; some as a maintainer.
- ## Must
1. **Don't be a jerk.** When people engage with your project, don't be dismissive, haughty, or mean. There are definitely things you should ignore, and sometimes posts (or people) you need to block, but rudeness is never rewarded.There are projects I know I will never contribute to because I saw how _someone else_ was treated by the maintainers.- ## Good
1. **Have a scope.** It is extremely demoralizing to make a PR that does a thing, and have it rejected because "our project doesn't do that." Save that person the work, and/or encourage opening issues to discuss it first.2. **Don't summarily close stale issues.**[^stale] It is _terrible_ from the perspective of an invested party to be subscribed to a bug report that is then locked (especially by a "needs bump or else" automation). You can close issues as `WONTFIX` or `DUPLICATE` if that's the proper resolution, but otherwise leave them open.The upvoting is important and should not be fragmented. It is also extremely frustrating to discover years later that someone opened _the same issue_ but without the previous context, and no one who was previously subscribed knew about it.On the other hand: **Hide "me too" comments** that lack additional information, and gently suggest upvoting OP instead.3. **Builds should be easy.** This may be implied by [the previous answer][matthew], but I want it to be explicit: If people can't build your project with little-to-no effort, a large contingent are never going to contribute and won't ever tell you why.Clone, (optionally) install dependencies, and make. Nobody downloads your source code to fuss with architecture differences or toolchain versions. If someone is sufficiently engaged to get past that, or to post an issue about a build error, great! You've found a good one! But if they decide it wasn't worth it, you may never hear from them again.- ## Maybe
1. **Tag appropriate issues as "good first issue."** I am not certain that this helps, but it's low-effort and probably doesn't hurt.In my experience, most people who want to contribute want to fix _their_ pain point, not _your_ pain point. However, for those genuine altruists who are just a bit intimidated by your existing codebase, it might be helpful to suggest a good, encapsulated entry-point into making a change to the system.- [^stale]: This either a clarification or a rebuttal to [Matthew's][matthew] #6 "Clean out the tumbleweeds."
- [matthew]: https://software.codidact.com/posts/291131/291133#answer-291133
- [Matthew's list][matthew] is pretty good, although I don't think one has to do _all_ the things on it as a "minimum." I offer one minimum and a couple nice-to-haves. Some of these I have learned as a contributor; some as a maintainer.
- ## Must
- ### Don't be a jerk
- When people engage with your project, don't be dismissive, haughty, or mean. There is definitely bad behavior you should ignore, and sometimes posts (or people) you need to block, but rudeness is never rewarded.
- There are projects I will never contribute to because I saw how _someone else_ was treated by the maintainers.
- ## Good
- ### Have a scope
- It is demoralizing for a contributor to make a PR that does a thing, and have it rejected because "our project doesn't do that." Save that person the work, and/or encourage opening issues to discuss it first.
- ### Don't summarily close stale issues[^stale]
- Subscribers to a bug report that is then locked (especially by a "needs bump or else" automation) will lose their investment and any sense of continuity. You can close issues as `WONTFIX` or `DUPLICATE` if that's the proper resolution, but otherwise leave them open.
- The upvoting is important and should not be fragmented. It is also frustrating to discover years later that someone opened _the same issue_ but without the previous context, and no one who was previously subscribed knew about it.
- On the other hand: **Hide "me too" comments** that lack additional information, and gently suggest upvoting OP instead.
- ### Builds should be easy
- This may be implied by [the previous answer][matthew], but I want it to be explicit: If people can't build your project with little-to-no effort, a large contingent are never going to contribute and won't ever tell you why.
- All a contributer should need is to clone, (optionally) install dependencies, and make. Nobody downloads your source code to fuss with architecture differences or toolchain versions. If someone is sufficiently engaged to get past that, or to post an issue about a build error, great! You've found a good one! But if they decide it wasn't worth it, you may never hear from them again.
- ## Maybe
- ### Tag appropriate issues as "good first issue"
- I am not certain that this helps, but it's low-effort and probably doesn't hurt.
- In my experience, most people who want to contribute want to fix _their_ pain point, not _your_ pain point. However, for those genuine altruists who are just a bit intimidated by your existing codebase, it might be helpful to suggest a good, encapsulated entry-point into making a change to the system.
- [^stale]: This either a clarification or a rebuttal to [Matthew's][matthew] #6 "Clean out the tumbleweeds."
- [matthew]: https://software.codidact.com/posts/291131/291133#answer-291133
#3: Post edited
by
Michael
·
2024-03-25T20:03:01Z (8 months ago)
Clarify good-first
- [Matthew's list][matthew] is pretty good, although I don't think one has to do _all_ the things on it as a "minimum." I offer one minimum and a couple nice-to-haves. Some of these I have learned as a contributor; some as a maintainer.
- ## Must
- 1. **Don't be a jerk.** When people engage with your project, don't be dismissive, haughty, or mean. There are definitely things you should ignore, and sometimes posts (or people) you need to block, but rudeness is never rewarded.
- There are projects I know I will never contribute to because I saw how _someone else_ was treated by the maintainers.
- ## Good
- 1. **Have a scope.** It is extremely demoralizing to make a PR that does a thing, and have it rejected because "our project doesn't do that." Save that person the work, and/or encourage opening issues to discuss it first.
- 2. **Don't summarily close stale issues.**[^stale] It is _terrible_ from the perspective of an invested party to be subscribed to a bug report that is then locked (especially by a "needs bump or else" automation). You can close issues as `WONTFIX` or `DUPLICATE` if that's the proper resolution, but otherwise leave them open.
- The upvoting is important and should not be fragmented. It is also extremely frustrating to discover years later that someone opened _the same issue_ but without the previous context, and no one who was previously subscribed knew about it.
- On the other hand: **Hide "me too" comments** that lack additional information, and gently suggest upvoting OP instead.
- 3. **Builds should be easy.** This may be implied by [the previous answer][matthew], but I want it to be explicit: If people can't build your project with little-to-no effort, a large contingent are never going to contribute and won't ever tell you why.
- Clone, (optionally) install dependencies, and make. Nobody downloads your source code to fuss with architecture differences or toolchain versions. If someone is sufficiently engaged to get past that, or to post an issue about a build error, great! You've found a good one! But if they decide it wasn't worth it, you may never hear from them again.
- ## Maybe
1. **Tag issues as "good first issue."** I am not certain that this helps, but it's low-effort and probably doesn't hurt.- [^stale]: This either a clarification or a rebuttal to [Matthew's][matthew] #6 "Clean out the tumbleweeds."
- [matthew]: https://software.codidact.com/posts/291131/291133#answer-291133
- [Matthew's list][matthew] is pretty good, although I don't think one has to do _all_ the things on it as a "minimum." I offer one minimum and a couple nice-to-haves. Some of these I have learned as a contributor; some as a maintainer.
- ## Must
- 1. **Don't be a jerk.** When people engage with your project, don't be dismissive, haughty, or mean. There are definitely things you should ignore, and sometimes posts (or people) you need to block, but rudeness is never rewarded.
- There are projects I know I will never contribute to because I saw how _someone else_ was treated by the maintainers.
- ## Good
- 1. **Have a scope.** It is extremely demoralizing to make a PR that does a thing, and have it rejected because "our project doesn't do that." Save that person the work, and/or encourage opening issues to discuss it first.
- 2. **Don't summarily close stale issues.**[^stale] It is _terrible_ from the perspective of an invested party to be subscribed to a bug report that is then locked (especially by a "needs bump or else" automation). You can close issues as `WONTFIX` or `DUPLICATE` if that's the proper resolution, but otherwise leave them open.
- The upvoting is important and should not be fragmented. It is also extremely frustrating to discover years later that someone opened _the same issue_ but without the previous context, and no one who was previously subscribed knew about it.
- On the other hand: **Hide "me too" comments** that lack additional information, and gently suggest upvoting OP instead.
- 3. **Builds should be easy.** This may be implied by [the previous answer][matthew], but I want it to be explicit: If people can't build your project with little-to-no effort, a large contingent are never going to contribute and won't ever tell you why.
- Clone, (optionally) install dependencies, and make. Nobody downloads your source code to fuss with architecture differences or toolchain versions. If someone is sufficiently engaged to get past that, or to post an issue about a build error, great! You've found a good one! But if they decide it wasn't worth it, you may never hear from them again.
- ## Maybe
- 1. **Tag appropriate issues as "good first issue."** I am not certain that this helps, but it's low-effort and probably doesn't hurt.
- In my experience, most people who want to contribute want to fix _their_ pain point, not _your_ pain point. However, for those genuine altruists who are just a bit intimidated by your existing codebase, it might be helpful to suggest a good, encapsulated entry-point into making a change to the system.
- [^stale]: This either a clarification or a rebuttal to [Matthew's][matthew] #6 "Clean out the tumbleweeds."
- [matthew]: https://software.codidact.com/posts/291131/291133#answer-291133
#2: Post edited
by
Michael
·
2024-03-25T17:23:37Z (8 months ago)
Delete remnant of deleted footnote.
[Matthew's list][matthew] is pretty good, although I don't think one has to do _all_ the things on it as a "minimum." I will offer some minimums and some nice-to-haves. Some of these I have learned as a contributor; some as a maintainer.- ## Must
- 1. **Don't be a jerk.** When people engage with your project, don't be dismissive, haughty, or mean. There are definitely things you should ignore, and sometimes posts (or people) you need to block, but rudeness is never rewarded.
- There are projects I know I will never contribute to because I saw how _someone else_ was treated by the maintainers.
- ## Good
1. **Have a scope.** It is extremely demoralizing to make a PR that does a thing, and have it rejected because "our project doesn't do that."[^scope] Save that person the work, and/or encourage opening issues to discuss it first.- 2. **Don't summarily close stale issues.**[^stale] It is _terrible_ from the perspective of an invested party to be subscribed to a bug report that is then locked (especially by a "needs bump or else" automation). You can close issues as `WONTFIX` or `DUPLICATE` if that's the proper resolution, but otherwise leave them open.
- The upvoting is important and should not be fragmented. It is also extremely frustrating to discover years later that someone opened _the same issue_ but without the previous context, and no one who was previously subscribed knew about it.
- On the other hand: **Hide "me too" comments** that lack additional information, and gently suggest upvoting OP instead.
- 3. **Builds should be easy.** This may be implied by [the previous answer][matthew], but I want it to be explicit: If people can't build your project with little-to-no effort, a large contingent are never going to contribute and won't ever tell you why.
- Clone, (optionally) install dependencies, and make. Nobody downloads your source code to fuss with architecture differences or toolchain versions. If someone is sufficiently engaged to get past that, or to post an issue about a build error, great! You've found a good one! But if they decide it wasn't worth it, you may never hear from them again.
- ## Maybe
- 1. **Tag issues as "good first issue."** I am not certain that this helps, but it's low-effort and probably doesn't hurt.
- [^stale]: This either a clarification or a rebuttal to [Matthew's][matthew] #6 "Clean out the tumbleweeds."
- [matthew]: https://software.codidact.com/posts/291131/291133#answer-291133
- [Matthew's list][matthew] is pretty good, although I don't think one has to do _all_ the things on it as a "minimum." I offer one minimum and a couple nice-to-haves. Some of these I have learned as a contributor; some as a maintainer.
- ## Must
- 1. **Don't be a jerk.** When people engage with your project, don't be dismissive, haughty, or mean. There are definitely things you should ignore, and sometimes posts (or people) you need to block, but rudeness is never rewarded.
- There are projects I know I will never contribute to because I saw how _someone else_ was treated by the maintainers.
- ## Good
- 1. **Have a scope.** It is extremely demoralizing to make a PR that does a thing, and have it rejected because "our project doesn't do that." Save that person the work, and/or encourage opening issues to discuss it first.
- 2. **Don't summarily close stale issues.**[^stale] It is _terrible_ from the perspective of an invested party to be subscribed to a bug report that is then locked (especially by a "needs bump or else" automation). You can close issues as `WONTFIX` or `DUPLICATE` if that's the proper resolution, but otherwise leave them open.
- The upvoting is important and should not be fragmented. It is also extremely frustrating to discover years later that someone opened _the same issue_ but without the previous context, and no one who was previously subscribed knew about it.
- On the other hand: **Hide "me too" comments** that lack additional information, and gently suggest upvoting OP instead.
- 3. **Builds should be easy.** This may be implied by [the previous answer][matthew], but I want it to be explicit: If people can't build your project with little-to-no effort, a large contingent are never going to contribute and won't ever tell you why.
- Clone, (optionally) install dependencies, and make. Nobody downloads your source code to fuss with architecture differences or toolchain versions. If someone is sufficiently engaged to get past that, or to post an issue about a build error, great! You've found a good one! But if they decide it wasn't worth it, you may never hear from them again.
- ## Maybe
- 1. **Tag issues as "good first issue."** I am not certain that this helps, but it's low-effort and probably doesn't hurt.
- [^stale]: This either a clarification or a rebuttal to [Matthew's][matthew] #6 "Clean out the tumbleweeds."
- [matthew]: https://software.codidact.com/posts/291131/291133#answer-291133
#1: Initial revision
by
Michael
·
2024-03-25T16:07:16Z (8 months ago)
[Matthew's list][matthew] is pretty good, although I don't think one has to do _all_ the things on it as a "minimum." I will offer some minimums and some nice-to-haves. Some of these I have learned as a contributor; some as a maintainer.
## Must
1. **Don't be a jerk.** When people engage with your project, don't be dismissive, haughty, or mean. There are definitely things you should ignore, and sometimes posts (or people) you need to block, but rudeness is never rewarded.
There are projects I know I will never contribute to because I saw how _someone else_ was treated by the maintainers.
## Good
1. **Have a scope.** It is extremely demoralizing to make a PR that does a thing, and have it rejected because "our project doesn't do that."[^scope] Save that person the work, and/or encourage opening issues to discuss it first.
2. **Don't summarily close stale issues.**[^stale] It is _terrible_ from the perspective of an invested party to be subscribed to a bug report that is then locked (especially by a "needs bump or else" automation). You can close issues as `WONTFIX` or `DUPLICATE` if that's the proper resolution, but otherwise leave them open.
The upvoting is important and should not be fragmented. It is also extremely frustrating to discover years later that someone opened _the same issue_ but without the previous context, and no one who was previously subscribed knew about it.
On the other hand: **Hide "me too" comments** that lack additional information, and gently suggest upvoting OP instead.
3. **Builds should be easy.** This may be implied by [the previous answer][matthew], but I want it to be explicit: If people can't build your project with little-to-no effort, a large contingent are never going to contribute and won't ever tell you why.
Clone, (optionally) install dependencies, and make. Nobody downloads your source code to fuss with architecture differences or toolchain versions. If someone is sufficiently engaged to get past that, or to post an issue about a build error, great! You've found a good one! But if they decide it wasn't worth it, you may never hear from them again.
## Maybe
1. **Tag issues as "good first issue."** I am not certain that this helps, but it's low-effort and probably doesn't hurt.
[^stale]: This either a clarification or a rebuttal to [Matthew's][matthew] #6 "Clean out the tumbleweeds."
[matthew]: https://software.codidact.com/posts/291131/291133#answer-291133