> On May 22, 2016, at 18:12, Clayton Daley <clayton.da...@gmail.com> > wexternalote: > > "You can't: > require test coverage, > require documentation, > require coding standard compliance, > require people to file a ticket before sending a patch to the mailing list, > The first three of these are *already* norms in all of the OSS projects of > this caliber and the 4th doesn't make sense in a Github/Bitbucket/Gitlab > world (and I fortunately avoided its predecessors). In fact, I'd be a little > worried if the first there weren't required in a project. ResourceSpace is > the only one I can think of that doesn't require them and I wouldn't touch it > with a 10 foot pole if there were acceptable (free) alternatives. So I don't > see the link between your success enforcing three norms of good OSS projects > and your desire to break a 4th.
To make a long story short: we pretty much invented these norms, and were doing them a long time before other projects got on the bandwagon, over many, very loud objections. That said, I don't want to overstate the case. Test coverage was a huge deal. Doc coverage was a huge deal. This idea with PRs is a very small thing, maybe not the best idea, and not something we're unanimous about or dead set on. But the "all your friends are jumping off a bridge" argument against doing it just isn't very compelling. > The idea that PRs are a substantial burden has caused me pause. Normally, a > PR is a chance to give back to a project rather than freeload. In most > projects, new features are part of a virtuous cycle: a new feature tends to > benefit a large fraction of the user base and expand the user base... which > draws more contributors. The issue is not that PRs are, inherently, a "burden". But, before I try to rephrase the issue with too many simultaneously open PRs, I should probably describe the tremendous asymmetry between core maintainers and external contributors. This asymmetry is general to all open source projects, not particularly specific to Twisted at all. If you listen to Nadia Eghbal's various comments about funding open source (motivated by <https://medium.com/@nayafia/how-i-stumbled-upon-the-internet-s-biggest-blind-spot-b9aa23618c58#.vy4hlzcr4>) you hear this complaint repeated by lots of project maintainers. External contributors typically have an initial interest in landing one "contribution", which is something that benefits them (whether personally or their company) specifically, rather than something that benefits the community at large. Transforming that initial interest into a long-term commitment to the project is very challenging for maintainers. Even if an improvement is specific to the contributor who is making it, of course, there will be others like them who want similar improvements, so it's never a purely selfish or purely altruistic motivation for making the contribution; it's a mix. And general benefits are good for the core maintainers, of course, since it makes their long-term maintenance job easier, and it does attract more people to the project. But that benefit has to be balanced with a cost. The cost is that it takes time and energy to code-review contributions. This is the source of a lot of friction between core maintainers and external contributors: contributors feel that they are generously giving their time and energy to the project, and it's rude of the project to make them jump through any hoops to get it accepted, whether that's test coverage, documentation, pre-commit code review, coding standard compliance, or, in this case, learning a slightly weird workflow. External contributors can affect this balance a lot, by making sure that their contributions are already as close as possible to acceptable. But even if they do, the ratio of external contributors to core maintainers is almost always far greater than 1; the only way that external contributors can _really_ affect this balance is to become core maintainers :). And this asymmetry brings us to why it's important to keep the 'Review Queue' short. To rephrase what I said earlier in this thread, if there are so many open PRs that reviewers don't know which ones to look at first, then the sorting algorithm will be "whichever ones my friends want me to look at first", which means we need to maintain a clear division between things-we-are-looking-at and things-we-are-not-looking-at, to maximize the effectiveness of the limiting factor of code reviewer time for impact on the latency of time it takes to get feedback on a potential change. Sorry that this is a bit long-winded but I really just object to the premise that the point is that I don't care about contributors. I care about contributors a great deal; this is why I want a carefully designed process that doesn't shut them out or waste their time. > Especially given the recent deprecations (old, unmaintained protocols), it > seems that Twisted doesn't work like this. If another user adds another > protocol, it doesn't make the system better for most users. In fact, it > makes sense that it actually increases the maintenance burden. This is true of all features for all projects, though. More code == more maintenance. > I tried to look for myself, but was reminded that I don't know the internals > well enough... are patches on non-central protocols a big part of the > backlog? Or is the backlog mostly core features (like reactors or IO > infrastructure) that most projects depend upon? I don't think we have any good metrics on the backlog, unfortunately. But certainly most of the maintenance work has been maintenance, like porting existing code to python 3, improving test coverage, and implementing improvements to TLS. -glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
