Mike, I think that would be awesome for reviewers (and that is where most of my time is spent on the review side), but I also think that sets a really high bar for contribution. Many of the users who submit pull requests are first-time contributors or new to the project, and I believe the easier we can make contributing, the more we will grow and strengthen our community. Someone might have experience with a weird protocol or multithreading and be able to offer expertise there, but not have the familiarity with Docker. For experienced users contributing advanced functionality though, I think it would be excellent and definitely streamline the review process.
Andy LoPresto alopre...@apache.org alopresto.apa...@gmail.com PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Feb 1, 2018, at 9:31 AM, Mike Thomsen <mikerthom...@gmail.com> wrote: > > It looks like there are at least 10 new processors and services in the > backlog, and quite a few modifications to existing ones. > > Something I think would really help here is to expand the scope of > requirements for submitting a new processor for code review to include: > > 1. docker-compose file that sets up a complete development environment w/ > appropriate port mappings that just work when used with NiFi running > outside of Docker on the reviewer's machine. > > 2. A sample flow, a really KISS example w/ GenerateFlowFile or something > that spits out a query or sample that can let the reviewer really see the > submitter's idea of what the input should look like. > > Whether those are stored on a Wiki or in the Git repo doesn't really > matter. I think submitting those artifacts will really reduce the burden of > quickly going from "LGTM, JUnits seem to run" to "OK, I see it actually > running as expected." > > On Tue, Jan 30, 2018 at 12:38 AM, James Wing <jvw...@gmail.com> wrote: > >> This is a great idea, Mark, thanks for proposing it. 30 days after last >> review comment seems like a good, enforceable standard. >> >> James >> >> On Mon, Jan 29, 2018 at 8:29 AM, Mark Payne <marka...@hotmail.com> wrote: >> >>> All, >>> >>> We do from time to time go through the backlog of PR's that need to be >>> reviewed and >>> start a "cleansing" process, closing out any old PR's that appear to have >>> stalled out. >>> When we do this, though, we typically will start sending out e-mails >>> asking if there are >>> any stalled PR's that we shouldn't close and start trying to decipher >>> which ones are okay >>> to close out and which ones are not. This puts quite an onus on the >>> committer who is >>> trying to clean this up. It also can result in having a large number of >>> outstanding Pull Requests, >>> which I believe makes the community look bad because it gives the >>> appearance that we are >>> not doing a good job of being responsive to Pull Requests that are >>> submitted. >>> >>> I would like to propose that we set a new "standard" that is: if we have >>> any Pull Request >>> that has been stalled (and by "stalled" I mean a committer has reviewed >>> the PR and did >>> not merge but asked for clarifications or modifications and the >>> contributor has not pushed >>> any new commit or responded to the comments) for at least 30 days, that >> we >>> go ahead >>> and close the Pull Request (after commenting on the PR that it is being >>> closed due to a lack >>> of activity and that the contributor is more than welcome to open a new >> PR >>> if necessary). >>> >>> I feel like this gives contributors enough time to address concerns and >> it >>> is simple enough >>> to create a new Pull Request if the need arises. Alternatively, if the >>> contributor realizes that >>> they need more time, they can simply comment on the PR that they are >> still >>> interested in >>> working on it but just need more time, and the simple act of commenting >>> will mean that the >>> PR is no longer stalled, as defined above. >>> >>> Any thoughts on such a proposal? Any better alternatives that people have >>> in mind? >>> >>> Thanks >>> -Mark >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
