Inspired by Josh’s comment in another thread, here are some thoughts on how the current issues and PRs could be addressed. Just random kibitzing, would like to hear opinions.
Use GitHub Labels
Using labels could indicate where others can help out:
- needs work: PRs that you’d like to merge but need changes first.
- needs testing: PRs that appear ready but need to be tested on a live system. This should encourage users to try them out and comment with results.
I’m not interested in trying PRs that have no chance of getting merged, but I’m more than happy to guinea pig stuff that looks good and just needs stabilization and small tweaks.
Pull Requests
This actually looks pretty tractable. There are only ten, and half of them seem like they’re pretty much ready.
#638 better warning: I’d apply needs work label, let discussion continue.
#634 share imap logins: apply needs work and suggest figuring out all the relevant dovecot switches. Then ask the submitter to write up a plan, try it, and ensure it fixes the warnings. Repeat until success.
#632 default_process_limit: apply needs work and tell the submitter to coordinate with #634 to figure out these config settings once and for all.
#630 ssl replace-all: tell the handsome submitter a better way to force an ssl cert to be replaced, even if it isn’t near expiration.
#587 cron at 3am: apply needs testing, lean toward merging.
#584 display mem/disk in admin: Apply needs work. This PR is bringing in other changes so ask submitter to rebase against proper branch or clean it up.
#510 enable zlib: Apply needs testing, lean toward merging
#409 rcmcarddav: Apply needs work, ping the original submitter for an update.
#397 slowlog: apply needs testing, lean toward merging.
#338 dockerization: tell the submitters to break up this PR: one that only adds Docker files (guaranteed to be a no-op for anyone that isn’t using Docker), and a few small, well-focused PRs that make the absolute minimum changes necessary to existing files. $IS_DOCKER is a code smell and maintenance burden, I’d probably reject PRs that use it.
Issues
91? It’s hopeless…
I’d make a quick pass and apply wishlist and waiting for response labels where they obviously apply.
Now, listing issues without these labels looks a little less dire: https://github.com/mail-in-a-box/mailinabox/issues?utf8=✓&q=is%3Aissue+is%3Aopen+-label%3Awishlist+-label%3Awaitingforresponse
Then I’d take a slower pass and ensure that each issue has a clear and attainable goal. If not, I’d ask the submitter to clarify and apply waiting for response.
Now, down to fiftyish issues, I’d apply a needs work label to half of them and hope someone wanders along to turn them into PRs. I’d viciously close the other half with barely coherent rants about lazy ISPs, then adjourn to sip brandy and dream of a world with a less screwed up tech infrastructure.
Something like that.
Certainly tell me how I can help out.