| Re: [paho-dev] Is paho.mqtt.python actively maintained? |
Hello!
I am not an experienced developer by any stretch of any imagination. I have been fortunate to use GitHub to work on many, many different interests that I pursue. My use of GitHub is limited to fork/clone sadly. Pierre's note caught my attention:
"
I have found that github issues are problematic, due to github culture of people asking questions in issues. These often don't get answered, or when they do, stay open. The nature of issues and notifications is that the maintainers get told about the question, but the community does not. The result is an issue tracker full of junk that makes it very hard to use as a reporter -- it's hard to search -- and also very hard to use for the maintainer."
There are some repositories where an effort has been made to add extra sections precisely to address some of concerns raised by Pierre. The key aspect of these refinements is to use templates and have dedicated sections. Some examples are:
GitHub does provide sample templates for Bugs. I'll be the first to admit that many times I have had to resort to use the Bugs section when the note should have been pasted to a HOW-TO (which did not exist in that specific repository). Perhaps my suggestion is work overload for paho-mqtt-python but perhaps a simple declaration (with illustration in README.md) on the desired way to submit feedback on the repository could be considered.
Again, I am newbie in these matters. Please understand that this response is from an individual who relies on paho-mqtt-python and I will try my best to help with any testing that I can perform. Thanks.
Regards,
--- Matha.
Pierre Fersing <pierre.fersing@xxxxxxxxxxx> writes:I'm one of the committer on this repository. I'm short on time to monitor PRs and issues (hence the high number of issues :( ). But I still watch the mailing list, so if you have any serious issues or a PR that needs some attention, I'll find some time for them. If you want to help supporting this project, you're more than welcome. I'll try to find a some time this summer to make a release, it helps showing that this project is not dead.Thanks for speaking up here. I maintain unison, and help with several others, so I understand that maintaining a project is much harder than many think. I have gradually moved to optimize for maintainer cycles at the expense of niceties. I have found that github issues are problematic, due to github culture of people asking questions in issues. These often don't get answered, or when they do, stay open. The nature of issues and notifications is that the maintainers get told about the question, but the community does not. The result is an issue tracker full of junk that makes it very hard to use as a reporter -- it's hard to search -- and also very hard to use for the maintainer. Plus, many of these questions are not really about the package itself, but are about not knowing programming, networking, or debugging. To deal with this, my view is that questions and requests for help should be absolutely prohibited in issues, with the README telling people to join the list and ask there instead. This means that questions do not linger (there are 238 open issues now, many of them not valid), and people other than the maintainers can answer. I've been doing this in unison and it has helped keep the issue list under control. I don't want to cross into being a maintainer of paho mqtt, as I am doing too much maintaining in general, but what I'd do is: Fix the most recent commit, perhap via what I just posted. Fix the labels in use not to have spaces. That just adds friction to using them in search terms, even though I'm sure it is doable. Add to README as the very first thing a "reporting bugs and asking for help" section that says the issue tracker is only for well-articulated broadly-useful feature requests and bugs with evidence, with help requests belonging on (this?) mailinglist. Store a "Please see README about asking for help; use the mailinglist instead of the issue tracker" in your cut buffer and start just pasting that and hitting close. I bet you can can close 40 bugs/hour and will close a large fraction. Continue to do this as questions come in, and ask anyone who responds to questions in the issue tracker to stop. Add a feedback label and defined it as "feedback requested; may be closed in 30 days", and for any bug report that is more than a year old, add feedback and paste it "please retest with up-to-date git master". After 30 days, look at the feedback bugs, and if you don't think they are super important, just hit close. I realize this may seem harsh, but letting the issue tracker be not useful for everyone I consider to be a much worse situation. Of course, then the usual looking over PRs as you allude to. I would also feel free to ask people to fix up PRs so that they are - rebased against recent enough master - clean changesets - any fixes are rebased into the commits so they are clean to merge. I have become more and more willing to ask other people to do more and to produce higher-quality PRs. Greg _______________________________________________ paho-dev mailing list paho-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev