I think this is not only for code but also for doc and reno. We should fix it basically, especially about doc/reno. But I don't think it should be in the same patch if the mistake isn't critical which means *nitpicks*. I think we can fix them with following patches if we need to fix it.
Otherwise, writing reno/doc might be a really difficult and hard work for ESL people like me. -- Masayuki On 05/30, Ghanshyam Mann wrote: > Thanks for making it formal process which really helps. I think most > of the people usually does that but yes it is always helpful to be > added as principles. > > I have gotten mix feedback on fixing other patches in past and when i > got anger by author i try to leave comment for a day or two then fix > if it is really needed otherwise just go with follow-up. > > One question - This only applies to code nitpick only right? not > documentation or releasenotes. For doc and reno, we should fix spell > or grammar mistake etc in same patch. > > -gmann > > > On Tue, May 29, 2018 at 10:55 PM, Julia Kreger > <juliaashleykre...@gmail.com> wrote: > > During the Forum, the topic of review culture came up in session after > > session. During these discussions, the subject of our use of nitpicks > > were often raised as a point of contention and frustration, especially > > by community members that have left the community and that were > > attempting to re-engage the community. Contributors raised the point > > of review feedback requiring for extremely precise English, or > > compliance to a particular core reviewer's style preferences, which > > may not be the same as another core reviewer. > > > > These things are not just frustrating, but also very inhibiting for > > part time contributors such as students who may also be time limited. > > Or an operator who noticed something that was clearly a bug and that > > put forth a very minor fix and doesn't have the time to revise it over > > and over. > > > > While nitpicks do help guide and teach, the consensus seemed to be > > that we do need to shift the culture a little bit. As such, I've > > proposed a change to our principles[1] in governance that attempts to > > capture the essence and spirit of the nitpicking topic as a first > > step. > > > > -Julia > > --------- > > [1]: https://review.openstack.org/570940 > > > > __________________________________________________________________________ > > 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 -- Happy Hacking!! Masayuki Igawa GPG fingerprint = C27C 2F00 3A2A 999A 903A 753D 290F 53ED C899 BF90
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
