Honestly, I think there's somewhat of an infrastructure/process here (i.e. not having http://contributing.md not auto-closing PRs with referral). But the much larger issue is that there's basically no human resources to do that kind of work.
-
-
Replying to @AndresFreundTec @ascherbaum and
This is the real crux of the matter. The notion that making providing patches or PR's easier is IMO pointless until we solve how to deal with reviewing them. Which is really a resource issue. If someone really truly wants to help the project then review patches.
1 reply 0 retweets 0 likes -
Replying to @dave_cramer @AndresFreundTec and
This is a chicken-egg problem: you don't get small patches for review, because the process is complicated. And without small patches, you don't grow many new reviewer.
2 replies 0 retweets 0 likes -
Replying to @ascherbaum @dave_cramer and
The issue is with having 2 places to do one thing. Mailing lists excel at being a place that can align conversation with code. You link issues with solutions with conversations with code. Github doesn't have a good workflow for conversations that can unfold on mailing lists.
1 reply 0 retweets 1 like -
Replying to @Eulerizeit @ascherbaum and
And while people seem to be bemoaning the use of mailing lists as archaic, they are extremely valuable for history. I miss them terribly on the pgJdbc project.
1 reply 0 retweets 0 likes -
Replying to @dave_cramer @Eulerizeit and
I do think there's a serious issue in that one cannot realistically assume that a casual contributor can read -hackers. It's just too much.
2 replies 0 retweets 1 like -
Replying to @AndresFreundTec @dave_cramer and
there is no need to actually to that to contribute though, is it? I mean, you'll need to cherry pick and read some (through our archives ,or some other aggregate site), but you don't need to actually subscribe with full mail delivery.
3 replies 0 retweets 0 likes -
Replying to @magnushagander @dave_cramer and
Well, then every email of such a casual contributor will get delayed. Sure, they could subscribe, and then disable delivery. But that's a somewhat arcane process.
2 replies 0 retweets 0 likes -
Replying to @AndresFreundTec @dave_cramer and
As for subscribe/disable, the process is "pick list, pick address, click confirm, click edit, check box to disable delivery". How is that arcane? And would it help to put that checkbox on subscription page?
1 reply 0 retweets 0 likes -
Replying to @magnushagander @dave_cramer and
I'd *bet* that the number of new contributors that would think of doing so so is pretty close to zero. They'll suffer through the torrent of emails for a few days, and then unsubscribe. If we documented that as a basic step of a new "casual contributor guide", maybe?
3 replies 0 retweets 0 likes
Putting it on the subscription page would probably help. With an explanation like "Some of these lists are high volume. It can be advisable to subscribe and disable email delivery, allowing to send emails without delay and receive replies."
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.