Earlier quoted context omitted.
Maybe the missing feature here is that GitHub should "just" automatically minimize +1 comments. Or even better, delete them without sending a notification to maintainers/watchers, and automagically have the user who posted it add a thumbs up to the original issue. (Personally, I would consider them spam.)
> automagically have the user who posted it add a thumbs up to the original issue. I was astonished that they didn't do this when they introduced the emoji reactions feature.
New tools for open source maintainers
31–40 of 67 posts
Re: New tools for open source maintainers
#32The "retirement" feature is a good start, but oddly over-engineered. Just stop allowing username reuse, period!
Re: New tools for open source maintainers
#33Re: New tools for open source maintainers
#34I get all this by not using github. Minimized comments: I run the mailing list and can enable moderation at any time. Retire namespace: I control the web server and so every aspect of the URL after the domain name. Unwanted pull requests: no different from unwanted anything else.
Downside: Holy shit fuck mailing lists. They're terrible . Major downside: You miss a huge percentage of possible contributors.
I remember I wanted to check out what was happening in Postgres, since it's my favourite database. But the sheer complexity of getting to the code diffs and comments and all that... I quickly gave up, because the environment was rather unfriendly to newcomers (actually, I didn't completely give up, I just browsed the Github mirror, which was the only usable part of their version control).
And I'm not blaming them, it works well for the core devs, but they can't expect many new contributors (and contributions are even things like documentation, tests etc.!). Which is a pity.
Re: New tools for open source maintainers
#35The main thing I want to hide in minimized comments are "+1 fix this plz!" comments on bugs, comments that add nothing above and beyond a thumbs-up reaction. The "reasons" Github offers for minimizing comments are: Spam, Abuse, Off Topic, Outdated, and Resolved. "+1" isn't exactly any of those. (I guess they're kinda "Spam" but they're not unsolicited commercial messages.)
Re: New tools for open source maintainers
#36Earlier quoted context omitted.
> automagically have the user who posted it add a thumbs up to the original issue. I was astonished that they didn't do this when they introduced the emoji reactions feature.
Part of the problem is deciding what the +1 should be attached to. Some people comment +1 just because they want to see a PR merged. Some +1s are intended to be associated with a specific comment.
I think it could be done on a per repository basis, like, basic behaviour rules just like at forums and other such communities. It's then up to the maintainer / moderators / whatever to allow or disallow +1-style comments, and what the 'punishment' would be. They could then also tweak a setting that auto hides comments if they're shorter than X characters.
Re: New tools for open source maintainers
#37Earlier quoted context omitted.
I'm really hoping they're only blocking PR's from non-collaborators if the PR description is empty. Requiring someone to be a collaborator on a repository to open a PR is a step backwards to me. It's really nice to notice a trivial fix like a typo when browsing the code, fix it in the integrated editor and hit PR right there. I could see having the option to disable PRs useful, but removing the functionality entirely
I think they meant, when the contributor is also not the author of the changes. At least I hope this is what they meant.
Re: New tools for open source maintainers
#38Earlier quoted context omitted.
Downside: Holy shit fuck mailing lists. They're terrible . Major downside: You miss a huge percentage of possible contributors.
I don't want to deal with people who think e-mail is terrible, or contributors who can't copy a URL from a page served up CGIT, do a "git clone" on it, and then mail off the results of "git format-patch" when they are done. This stuff is incredibly easy.
Re: New tools for open source maintainers
#39Earlier quoted context omitted.
It's not about email being easy. It's that I don't want my email getting out (spam and all that - you send one email to a bad behaving mailing list, and your email is all over the internet forever for spambots to harvest.)
Realistically if you've got commits in a public git repo, your email address is public no matter how they got there.
Re: New tools for open source maintainers
#40Earlier quoted context omitted.
Downside: Holy shit fuck mailing lists. They're terrible . Major downside: You miss a huge percentage of possible contributors.
This is fairly sad, because a lot of software is still maintained using mailing lists. Often not because it's the best solution, but because it's the least bad (for some). Also, if one wants to ensure that the whole lineage will be with us 20 years from now, a mailing list is a better bet than all the Gerrits and Githubs of the world. I remember I wanted to check out what was happening in Postgres, since it's my favo…
And I'm even worried about those... what will happen in a few years/decades from now, when the generation of devs that are using mailing lists is not active anymore?