Thanks for being brave enough to say it publicly. Not sure how many more times I can stomach reading such classic patches as "Optimize the link address" or "Replace six.iteritems() with .items()".
Yes, it is still possible for us to be an open community while also minimizing the amount of useless patches. Messages like the sample Matt provided are part of the solution. Resisting the urge to -2/force-abandon without explanation is part of the solution, too. But they aren't the whole solution. The TC's emerging Top 5 help-wanted list is a step in the right direction towards solving this problem. Let's publicize the crap out of that. And we can go further, with project-specific help wanted lists. And how about a better way to identify and promote issues which are both low-hanging fruit AND important (they aren't actually that rare!). Turning towards more radical solutions: 1) Bake something into git-review which will print out some agreed-up community guidelines for what constitutes a useful patch, as well as any repository-specific guidelines. To keep it reasonable, only show the message the first time a contributor submits to that repository. 2) Register fingerprints of common unhelpful patches and have a bot similar to Elastic Recheck automatically review and comment. 3) Delay spin-up of resource-intensive/long-running CI jobs until after some initial review has been added or time has passed. Authorized contributors, not necessarily synonymous with cores, can override the delay if there's a critical patch which needs to get through the queue quickly. Those are just some ideas off the top of my head, so feel free to tear me apart. Looking forward to seeing where this conversation goes this time around. On Thu, Sep 21, 2017 at 10:21 PM, Matt Riedemann <mriede...@gmail.com> wrote: > I just wanted to highlight to people that there seems to be a series of > garbage patches in various projects [1] which are basically doing things > like fixing a single typo in a code comment, or very narrowly changing http > to https in links within docs. > > Also +1ing ones own changes. > > I've been trying to snuff these out in nova, but I see it's basically a > pattern widespread across several projects. > > This is the boilerplate comment I give with my -1, feel free to employ it > yourself. > > "Sorry but this isn't really a useful change. Fixing typos in code comments > when the context is still clear doesn't really help us, and mostly seems > like looking for padding stats on stackalytics. It's also a drain on our CI > environment. > > If you fixed all of the typos in a single module, or in user-facing > documentation, or error messages, or something in the logs, or something > that actually doesn't make sense in code comments, then maybe, but this > isn't one of those things." > > I'm not trying to be a jerk here, but this is annoying to the point I felt > the need to say something publicly. > > [1] https://review.openstack.org/#/q/author:%255E.*inspur.* > > -- > > Thanks, > > Matt > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
