4 ms·

As an open source maintainer[1], the etiquette tips are great. However, I think +1 and status check comments are ok in certain situations where the issue might

by welder 4y ago

As an open source maintainer[1], the etiquette tips are great. However, I think +1 and status check comments are ok in certain situations where the issue might have been forgotten or it's a high priority issue. I also like when someone reminds me they're blocked by an issue. It helps me prioritize fixing bugs so I work on things actually affecting people instead of things nobody is using. Just be polite and your comments are welcome. [1] https://github.com/alanhamlett/pip-update-requirements https://github.com/alanhamlett/pip-update-requirements

pastage 4y ago
I guess the "be excellent to each other" note at the end of the post is basically be polite. Often there is a reason why simple request take time. It can be hard to describe why.
pabs3 4y ago
Prioritisation often becomes harder the closer you become to being an open source maintainer, since you're often more focused on software maintenance/internals than on using the software in real-life contexts. I feel like creating systems for open prioritisation is going to be an important "next step" in open source project management. Igalia did an experiment in open prioritisation in web browser development, but they tied it to funding, which helps with project viability but introduces a prioritisation bias towards people who have money to donate. https://www.igalia.com/open-prioritization/ https://www.igalia.com/open-prioritization/
- prox 4y ago
  Doesn’t monetization also indirectly help the other issues?
  - pabs3 4y ago
    Usually the maintainer's work is more money than they would ever get from monetization. Also the maintainer is one person, they can only do so much, eventually more people need to step up and do code/etc contributions.
- 2Gkashmiri 4y ago
  >Prioritisation often becomes harder the closer you become to being an open source maintainer, since you're often more focused on software maintenance/internals than on using the software in real-life contexts i contribute to a FOSS project. I am not a dev nor can i hire someone to do dev work so i assist the actual dev team into giving them real life use cases which brings out a lot of bugs which get fixed along the way. That way, instead of trying to achieve some sort of tangent "idea" of what a software is going to be and it becomes something the users can actually use and relate to. the software in question, when people are going to use it and will face "normal workflow bugs" for example, we can forget about adding new features. right? maybe they can go side by side but unless you are working on the bleeding edge software and do not expect anyone to use in production it can work but not otherwise. Also, by pointing out edge cases, the present software itself would become what would be called "battle tested" because most if not all the issues are fixed. that said, if a project had a good budget, a good roadmap, a thriving developer community and users who are using it, reporting bugs and people volunteering to fix stuff, we can think about experimenting but otherwise not
prox 4y ago
I think when an issue becomes highly ranked by users, it’s important that devs give clear feedback. In communication, acknowledgement is very important. Just say it if it’s not on the current to do list and when you project to be working on it (or not at all) It gives a clear feedback, and allow people to move on, fork it, stick with it, their choice. Politeness should be key.
- deleted 4y ago
  [deleted]
Aeolun 4y ago
> I also like when someone reminds me they're blocked by an issue. As a user, this feels weird to me. If I’m actually blocked by a bug you’ll receive a PR, not a +1. If I have the leisure to +1 I’m clearly not blocked enough for you to consider it pressing.
- freedomben 4y ago
  I think this needs a big qualifier. I feel the same way, when it's a project I'm capable of doing the work for. For example, I recently needed a way to deal with Stripe early fraud warnings and the library I used didn't have those yet, so I added them over a weekend[1]. However, there are tons of dependencies that we use for all sorts of things that are highly complex where very few people would be able to send a PR (openssl for example). Things in highly complex codebases, or deeply unfamiliar languages, etc. I maintain a forked linux driver for a wireless card for example, and I don't expect there's more than a handful of people that could hack on it without introducing tears and devastation. For the projects I maintain, I would just say, "if you can, please consider a PR. If you're not sure it would be accepted I'm happy to be asked! If you can't send a PR, give as much info as you can and be polite. With that we're good. [1]: https://github.com/beam-community/stripity_stripe/pull/728 https://github.com/beam-community/stripity_stripe/pull/728
- rowanG077 4y ago
  While in theory this would be great some issues are really not feasible for a first time contributor to work on.
II2II 4y ago
The author followed up by stating: > As time went on the wording of the +1s got stronger, people demanded that it be implemented and expected it to be scheduled into future milestones. I don't think they thought the +1 was an issue with respect to prioritization. Rather, it is an issue because it is a form of confirmation for users to behave in entitled ways.
jlkuester7 4y ago
This exactly! I am a solo maintainer on a very small Android app. I find it very useful when users vote for issues with the :thumbsup: emoji. Otherwise I have no real way of knowing which new features are popular with the community. Comments that add nothing to the issue but just create noise in the notification feed are annoying.
no_circuit 4y ago
I'm not so sure +1's or emojis are useful, except for maybe a few cases like you have a very large audience and they all send a thumbs-down emoji to protest a bad product or design decision -- recent c#/dotnet for example. Or the reminder ping from an affected user who is still interested in and using your project. The problem I believe is that a +1 or another reaction to an issue is simply a sample from all developers that viewed the project that bothered to leave a note. Chances are people are not using an open source project if they see a reasonably filed issue a long time ago that either was not addressed in any fashion whether it be a principled statement on why it can't be addressed yet, or that the project isn't interested in working on it. That obviously only works for small projects without a product manager. The issue persists on the large projects as well. The issue reactions set is just a sample of the all developers set that used or looked at the project. The only way to really know what is going on is telemetry and crash reports. Larger companies with thousands of crash reports, bug reports, and features requests can cluster them and figure out what to work on, along with a touch of good taste. Good taste is unfortunately important too. Unfortunately for telemetry a lot of people think it is a privacy issue... which it can be if the developer implements it poorly. And looks like GitHub only exposes traffic overall to your site [1] so you never know the population size is for people that are possibly affected by that issue -- so the relative +1 count is not reflective of reality. You might have a fighting chance if you use self-hosted GitLab or something with which you can grab granular traffic stats. [1] https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository https://docs.github.com/en/repositories/viewing-activity-and...
- matkoniecz 4y ago
  For me (participating in a small open source project) upvotes are useful - it is a confirmation that anyone else cares about that idea and that someone read what is being proposed and at least is not protesting. Multiple times I have no preference between two issues and worked on one with more reactions.
- plorkyeran 4y ago
  It's often not immediately obvious if a request is something a lot of people want but only one person took the time to write up, or if it's a very niche thing that only that person cares about. People who +1 an issue are not a great data set, but it's a lot better than nothing and it's basically zero effort to check. If I'm looking for something to work on and there's two issues that look like they'll take similar amounts of time, both seem like good ideas to implement, and I'm not sure which is more valuable, the number of +1s is a pretty decent tiebreaker.
rowanG077 4y ago
This. It can be an important signal an issue that a maintainer might think is low priority in reality isn't. Don't forget that a maintainer doesn't really know how their software is used.

by welder 4y ago

pastage 4y ago

I guess the "be excellent to each other" note at the end of the post is basically be polite. Often there is a reason why simple request take time. It can be hard to describe why.

pabs3 4y ago

Prioritisation often becomes harder the closer you become to being an open source maintainer, since you're often more focused on software maintenance/internals than on using the software in real-life contexts. I feel like creating systems for open prioritisation is going to be an important "next step" in open source project management. Igalia did an experiment in open prioritisation in web browser development, but they tied it to funding, which helps with project viability but introduces a prioritisation bias towards people who have money to donate. https://www.igalia.com/open-prioritization/ https://www.igalia.com/open-prioritization/

prox 4y ago
Doesn’t monetization also indirectly help the other issues?
- pabs3 4y ago
  Usually the maintainer's work is more money than they would ever get from monetization. Also the maintainer is one person, they can only do so much, eventually more people need to step up and do code/etc contributions.
2Gkashmiri 4y ago
>Prioritisation often becomes harder the closer you become to being an open source maintainer, since you're often more focused on software maintenance/internals than on using the software in real-life contexts i contribute to a FOSS project. I am not a dev nor can i hire someone to do dev work so i assist the actual dev team into giving them real life use cases which brings out a lot of bugs which get fixed along the way. That way, instead of trying to achieve some sort of tangent "idea" of what a software is going to be and it becomes something the users can actually use and relate to. the software in question, when people are going to use it and will face "normal workflow bugs" for example, we can forget about adding new features. right? maybe they can go side by side but unless you are working on the bleeding edge software and do not expect anyone to use in production it can work but not otherwise. Also, by pointing out edge cases, the present software itself would become what would be called "battle tested" because most if not all the issues are fixed. that said, if a project had a good budget, a good roadmap, a thriving developer community and users who are using it, reporting bugs and people volunteering to fix stuff, we can think about experimenting but otherwise not

prox 4y ago

I think when an issue becomes highly ranked by users, it’s important that devs give clear feedback. In communication, acknowledgement is very important. Just say it if it’s not on the current to do list and when you project to be working on it (or not at all) It gives a clear feedback, and allow people to move on, fork it, stick with it, their choice. Politeness should be key.

deleted 4y ago
[deleted]

Aeolun 4y ago

> I also like when someone reminds me they're blocked by an issue. As a user, this feels weird to me. If I’m actually blocked by a bug you’ll receive a PR, not a +1. If I have the leisure to +1 I’m clearly not blocked enough for you to consider it pressing.

freedomben 4y ago
I think this needs a big qualifier. I feel the same way, when it's a project I'm capable of doing the work for. For example, I recently needed a way to deal with Stripe early fraud warnings and the library I used didn't have those yet, so I added them over a weekend[1]. However, there are tons of dependencies that we use for all sorts of things that are highly complex where very few people would be able to send a PR (openssl for example). Things in highly complex codebases, or deeply unfamiliar languages, etc. I maintain a forked linux driver for a wireless card for example, and I don't expect there's more than a handful of people that could hack on it without introducing tears and devastation. For the projects I maintain, I would just say, "if you can, please consider a PR. If you're not sure it would be accepted I'm happy to be asked! If you can't send a PR, give as much info as you can and be polite. With that we're good. [1]: https://github.com/beam-community/stripity_stripe/pull/728 https://github.com/beam-community/stripity_stripe/pull/728
rowanG077 4y ago
While in theory this would be great some issues are really not feasible for a first time contributor to work on.

II2II 4y ago

The author followed up by stating: > As time went on the wording of the +1s got stronger, people demanded that it be implemented and expected it to be scheduled into future milestones. I don't think they thought the +1 was an issue with respect to prioritization. Rather, it is an issue because it is a form of confirmation for users to behave in entitled ways.

jlkuester7 4y ago

This exactly! I am a solo maintainer on a very small Android app. I find it very useful when users vote for issues with the :thumbsup: emoji. Otherwise I have no real way of knowing which new features are popular with the community. Comments that add nothing to the issue but just create noise in the notification feed are annoying.

no_circuit 4y ago

I'm not so sure +1's or emojis are useful, except for maybe a few cases like you have a very large audience and they all send a thumbs-down emoji to protest a bad product or design decision -- recent c#/dotnet for example. Or the reminder ping from an affected user who is still interested in and using your project. The problem I believe is that a +1 or another reaction to an issue is simply a sample from all developers that viewed the project that bothered to leave a note. Chances are people are not using an open source project if they see a reasonably filed issue a long time ago that either was not addressed in any fashion whether it be a principled statement on why it can't be addressed yet, or that the project isn't interested in working on it. That obviously only works for small projects without a product manager. The issue persists on the large projects as well. The issue reactions set is just a sample of the all developers set that used or looked at the project. The only way to really know what is going on is telemetry and crash reports. Larger companies with thousands of crash reports, bug reports, and features requests can cluster them and figure out what to work on, along with a touch of good taste. Good taste is unfortunately important too. Unfortunately for telemetry a lot of people think it is a privacy issue... which it can be if the developer implements it poorly. And looks like GitHub only exposes traffic overall to your site [1] so you never know the population size is for people that are possibly affected by that issue -- so the relative +1 count is not reflective of reality. You might have a fighting chance if you use self-hosted GitLab or something with which you can grab granular traffic stats. [1] https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/viewing-traffic-to-a-repository https://docs.github.com/en/repositories/viewing-activity-and...

matkoniecz 4y ago
For me (participating in a small open source project) upvotes are useful - it is a confirmation that anyone else cares about that idea and that someone read what is being proposed and at least is not protesting. Multiple times I have no preference between two issues and worked on one with more reactions.
plorkyeran 4y ago
It's often not immediately obvious if a request is something a lot of people want but only one person took the time to write up, or if it's a very niche thing that only that person cares about. People who +1 an issue are not a great data set, but it's a lot better than nothing and it's basically zero effort to check. If I'm looking for something to work on and there's two issues that look like they'll take similar amounts of time, both seem like good ideas to implement, and I'm not sure which is more valuable, the number of +1s is a pretty decent tiebreaker.

rowanG077 4y ago

This. It can be an important signal an issue that a maintainer might think is low priority in reality isn't. Don't forget that a maintainer doesn't really know how their software is used.