[Thursday24]

I have a question for experienced/skilled FOSS maintainers.

Are there any good ways to convert those who comment/suggest into contributors? I feel like instead of simply dismissing suggestions with "you get what you paid for", there must be a better way to handle the situation. Or perhaps I'm too naive on the topic

[em-bee]

this is really hard. i believe well meaning suggestions come from two types of people, those who don't know how to do it, and those who are to busy to do it themselves.

most of the time when i d̶r̶o̶p̶/contribute a suggestion as a user then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and contribute a patch.

and for those who don't know how, most likely the idea they had is more complex than they would be able to do as a first project, even if they were willing to learn. they are better off contributing in other areas that match their skill-level or enable them to learn. but how to motivate them to work on something that does not relate to their suggestion? maybe by arguing that if they help with those beginner tasks over there, then someone else can find the time to work on their idea, but it feels risky to make that kind of promise.

so i would rather focus on those who say they want to contribute something but don't know what because they feel they don't have the skill. those are hopefully motivated to learn. point them to issues that are suitable for people starting out.

and for anyone else: thank you for the suggestion. patches for this idea are welcome. (and optionally) feel free to ask for pointers how to get started.

[LelouBil]

I am a CS student, three years away from being a software engineer.

Since last year, I began reading the code of popular open source projects I use in order to determine the source of a problem I was having, and a lot of those times ended up as bug reports.

I now take the time to explain my whole reasoning into finding the bug and linking appropriate code snippets, but I'm still a bit afraid to start a PR on my own to fix it.

Since I did so on popular projects, with lots of issues/PR about half of them got ignored, or responded to a year later saying "not applicable to latest version".

That demotivates me a little about starting simple bug fixing PRs for big projects.

[einpoklum]

> I am a CS student, three years away from being a software engineer.

Three years away from having a degree. If you routinely do software engineering, you're a software engineering (possibly s/engineer/develop/ for a similar claim.)

> Since last year, I began reading the code of popular open source projects I use in order to determine the source of a problem I was having, and a lot of those times ended up as bug reports.

You are a saint! I would _love_ for people to read through my code looking for bugs and oddities.

Just remember that some FOSS projects are coded well, while others are coded horrendously.

> I now take the time to explain my whole reasoning into finding the bug and linking appropriate code snippets, but I'm still a bit afraid to start a PR on my own to fix it. > > Since I did so on popular projects, with lots of issues/PR about half of them got ignored, or responded to a year later saying "not applicable to latest version".

If you are considering writing a PR, get in touch with developers in a chatroom, or even over email, to coordinate this. They are likely to respond favorably to offers of PRs, and tell you things like "Don't do it now, we have a refactor coming up" or "base yourself off of this branch". And even if they say "not interested, don't bother" - you've still gotten useful information from them.

[em-bee]

first of all, don't give up. being ignored or overlooked is part of the FOSS experience. not every developer is available all the time, some only work during holidays or whenever the mood strikes them. some would prefer to ignore rather than reject someone, or (especially on popular projects) they may be so busy that they simply didn't see your submission.

when you fix a problem consider first of all, to do it for yourself. for your experience, or to solve a problem that you actually have.

fixing a problem and then finding out that it is already fixed, or that someone elses later fix was accepted ignoring yours, is also a common experience. there is nothing malicious about it. communication is just not perfect, and for some things, it may just be easier for the known and trusted developers to fix a problem themselves rather than to take the effort to review your contribution, even though taking care of your contribution would give them the opportunity to invite a new contributor. not every project has inviting new contributors on their radar.

my suggestion would be to look at projects that have an explicit policy of being welcoming to new contributors. they will either say on their site or in the documentation, or they have issues that are marked "good for beginners" "or good for a first contribution" or something similar.

work on such issues. join the community, their mailinglists, chat rooms, or whatever they use, and talk to other developers there. get to know the people, help other new contributors, make friends. later when one of your submissions is ignored or overlooked again, those new friends will be able to help you get attention to it. or they may know why it was ignored.

[bawolff]

Fwiw, dont be afraid to jump right in. Your patch might get rejected, but that happens to experienced people all the time too, and is no big deal.

PRs that get ignored is really demotivating. It can depend on which project a lot. If you're new to the project informally (and politely) chatting about your patch on project's irc/discord can help ensure you are not missing any social conventions.

[zzo38computer]

> i believe well meaning suggestions come from two types of people, those who don't know how to do it, and those who are to busy to do it themselves.

That is true, but there are also other issues, such as:

- Knowing most of what to write, but possibly missing some part of the code that you might not know of, which is needed to implement this feature.

They might not accept the change, leading to further things below:

- Possibility of breaking the interface and making it not compatible, especially with future versions of the official program if there are bit fields, structures, enumerations, etc that need to be extended.

- Needing to maintain your own fork of the project.

- If making multiple patches, making them to not interfere with each other.

I had made a repository of unofficial patches of SQLite; currently only contains my own patch for non-Unicode, and list of links to a few others. However, later I should perhaps add also such things as documents about enumerations, etc. Depending what needs to be done, possibly forking it and breaking the interface might have some advantages (can avoid some problems with the existing interface), but also disadvantages (more complicated to maintain).

> most of the time when i drop a suggestion then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and produce a patch.

I had considered this, and I think that you can specify reasons for dropping a suggestion, as well as details of what might be needed even if it is accepted but not implemented yet. As an example, I had made this list:

0. It already has this feature, or this capability can be easily done by the existing features.

1. Yes, I will likely add it soon (and may be working on it already).

2. Yes, but it is not a high priority; it may be added later.

3. Yes, but more work will be needed before it is added.

4. Probably; more work will be needed, and/or design decisions must be made, before it is added.

5. Maybe, but I am unlikely to implement it by myself; if you provide a patch then it will likely be added.

6. Unlikely, but possible. More work will be needed, and I probably will not add it by myself but a patch may be acceptable.

7. No, I consider it to be a bad idea. You may make your own fork of the project if you want it, though.

8. No, it is out of the scope of the intended project. You may make your own fork of the project if you want it.

9. No, it is probably too complicated and not very helpful anyways.

10. No, it is probably impossible. Forking it probably won't help.

11. The request is completely impossible; in addition to being impossible, it might also be incoherent, incomprehensible, unethical, etc.

In the case of bug fixes, it is a bit different, e.g. if you cannot figure out what is wrong, or if you do know what is wrong but you do not know how to fix it, etc.

[em-bee]

sorry, i slightly edited my text to clarify that i was talking from the user perspective and didn't mean to imply that i just drop/reject suggestions as a project owner. for that, your list of responses is very good.

[bawolff]

The internet is full of crazy people. "You get what you pay for" is usually used on people who are obnoxious and super entitled. Its not generally (at least in my experience) used on people who are making good faith suggestions. Its used on people who want you to be their personal slave. I generally have only ever used "you get what you pay for" or "i would be happy to provide a full refund" to extremely rude people, as a slightly more polite version of "fuck off".

People who make good faith suggestions can sometimes be converted, but you also have to respect that some people don't have the inclination or time but can still make good suggestions. Sort of similar to how on an internet forum most people are lurkers and that is ok. Good faith suggestions are really valuable to open source projects.