[Twisted-Python] on contributions
A few times recently (most recently in my email on Github) I have mentioned that I am more interested in getting more people to review Twisted tickets than in getting more people to write new patches to Twisted. Based on some feedback that other contributors have sent me privately, I'm afraid that this may have given the wrong impression. It's not that I don't want people to write patches for Twisted. I do. I want everybody to write patches for Twisted all the time! It's also not that I don't appreciate the time and effort that went into those patches. I do. In fact, it is because I appreciate that time and effort that I have said I want to optimize for reviews. It bothers me a lot that someone, having gone through the effort to craft a patch to Twisted, might have to wait for weeks or months for a reviewer to even thank them for that patch, let alone do a full review and give them the feedback they need to get it landed. I am constantly looking for ways to give quicker, feedback and better experiences to new contributors. I think the tools Github offers might help, but we (the core Twisted team) will still need to think of better ways to motivate ourselves and to induct others into the reviewer community. (If this has inspired you to do a review, there are plenty waiting: <http://twistedmatrix.com/trac/report/15>.) So, please, go on contributing patches to Twisted; I thank you for your contribution and I thank you doubly for your patience. Thanks, -glyph
On 5 June 2013 09:29, Glyph <glyph@twistedmatrix.com> wrote: [snip]
So, please, go on contributing patches to Twisted; I thank you for your contribution and I thank you doubly for your patience.
From my point of view, the fact that reviews take so long is one reason why committing patches to Twisted is not fun. So I think that you are right to focus on solving the review issues.
I have contributed a few patches to twisted.protocols.ftp and I think that one of the reason why it took so long to review the code, is due to the fact that no core developer really cares about FTP implementation. I know that everybody want Twisted to be big and great, but there are limited resources that needs to be managed. This is not a complain :), but what I wanted to say is that maybe it is better for Twisted to be a thinner library, and "downgrade" some of the code to independent projects. In this way, core developers will have more time to review more important core features, rather than looking at my minor fixes for FTP and later maintaining that code. Thanks! -- Adi Roiban
On Jun 5, 2013, at 12:37 AM, Adi Roiban <adi@roiban.ro> wrote:
On 5 June 2013 09:29, Glyph <glyph@twistedmatrix.com> wrote: [snip]
So, please, go on contributing patches to Twisted; I thank you for your contribution and I thank you doubly for your patience.
From my point of view, the fact that reviews take so long is one reason why committing patches to Twisted is not fun. So I think that you are right to focus on solving the review issues.
I have contributed a few patches to twisted.protocols.ftp and I think that one of the reason why it took so long to review the code, is due to the fact that no core developer really cares about FTP implementation. I know that everybody want Twisted to be big and great, but there are limited resources that needs to be managed.
Would you be interested in contributing to those resources by doing some reviews yourself? :) As a non-committer, you can do reviews of fixes contributed by committers (like me, exarkun, dreid, radix, therve...). It's up to the committer to decide whether your review was thorough enough, so it's their fault if you didn't do a good enough job :). If you clear those tickets out of the queue, it gives committers more time to review tickets from external contributors.
This is not a complain :), but what I wanted to say is that maybe it is better for Twisted to be a thinner library, and "downgrade" some of the code to independent projects.
In this way, core developers will have more time to review more important core features, rather than looking at my minor fixes for FTP and later maintaining that code.
There are, possibly, some features that Twisted could shed. But, based on my experience, I don't think that this is a major issue. A big reason that we need code review is to introduce external contributors to our coding practices so that they can work up to making more significant changes; in that sense, most reviews are similar unless they're really big. Also, one of the main advantages of Twisted is that it's a feature-rich suite of protocols which work together. It's nice to have common documentation and testing standards applied to all of them. (One day, after they've been maintained for another 10 years or so, maybe that'll even mean they all have good documentation and tests! :-)). -glyph
participants (2)
-
Adi Roiban
-
Glyph