Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Is paho.mqtt.python actively maintained?

Ian Craggs via paho-dev <paho-dev@xxxxxxxxxxx> writes:

> Using labels for questions/bugs/enhancement requests does make the
> management a bit easier, but this all depends on the maintainer(s)
> being able to routinely spend some time to keep on top of the
> workload. The more popular the repo, the greater the work needed to
> keep the lid on the backlog. Even the best PRs usually need work to
> accept them - tests, doc and then the ongoing maintenance.
>
> The upshot is, that even just keeping on top of answering questions
> and categorizing issues, is a not insignificant amount of work. I've
> found also that the more responsive you are, the more it seems to
> encourage questions.

I am not surprised.  As I wrote earlier, the fundamental problem with
questions-in-issues and github culture in general is that the
maintainers are subscribed to all issues by default, and usually nobody
else is.  Thus you talk about the maintainers answering questions, and
having to apply labels.  Vs the entire community, defined as mailing
list membership, being able to help, and having questions that just go
by simply be in the mailinglist archives and require no attention.  It
is completely unreasonable for this to be a maintainer-only job.

In the old days, nobody would have thought it the least bit reasonable
to ask a question in a bug tracker.  Every program had a mailinglist,
and you'd ask there, if you ahd read the docs and didn't figure
something out.  This entire concept of abusing trackers with questions
is github disease, which I see as likely calculated to drive site
traffic, and personally I refuse to deal with it.  I think everybody
else should also refuse.

> For those maintainers that are freelance, like I am now, there is the
> opportunity to solicit monetary support. I started a Github sponsors
> account hoping I might get many small contributions (as opposed to few
> larger ones), but it hasn't worked out that way so far.

I'm not surprised.   Really companies using code should contribute, but
that's remarkably difficult -- yet they pay for proprietary software
licenses all the time.


Back to the top