Hey Gareth, While I understand this whole mail was meant to enforce good practices (and that's good!), I think it went out quite wrong and agressive, and that's quite unnecessary.
Don't forget we have people from different languages and cultures in this project, and sometimes misunderstandings can happen. Keep the good work! -- Julien Le 26/03/2014 14:09, Gareth Aye a écrit : > Hi Gaia, > > tl;dr Please make a habit of explaining what the high-level goals of a > bug are when you file one. If you do one thing well as a software > developer, please make it communication. > > /* The longer version */ > > Sometimes our software doesn't work like we would like for it to. When > this happens at Mozilla, it's protocol to file a bug. Why is that? We > file bugs because we're /open/ and being open means being > /transparent/ about the work we're doing and /why/ /we're doing it/. > Often (and regrettably), I see bugs filed like this one > <https://bugzil.la/970138>. > > In bug 970138, Greg suggests that we should add a git pre-commit hook > to prevent patch authors from changing the file permissions on code > that gets checked into gaia. This is not commentary on whether or not > that should be done. This is commentary on how some folks /came to the > decision/ that it should be done and /how they/ /communicated it/ with > the organization and community. > > What was the rationale for this being prioritized and fixed? Greg's > and John's initial justification is that it "should be [fixed]". Is > this justification sufficient? :waynux and :yurenju seemed to think so > since they (respectively) patched and reviewed the bug. > > Interestingly, the pre-commit hook prevented me from making changes to > the scripts in $GAIA/tests/travis_ci/. I had to go back and in the > history to see where the pre-commit hook was introduced and then back > it out. Then I asked *three times* for explicit, high-level > justification for the work that was being done. > > The first time I asked, the patch author promptly made modifications > to the pre-commit hook and the reviewer made some more /code-level/ > suggestions. > > The second time I asked, Greg told me that the "broken part" of the > patch had been fixed by the update. > > The third time I asked, I was accused of not recognizing that the > problem I reported had been fixed by modifications to the pre-commit hook. > > By this point, I am feeling like/you had one job/*^(TM)* and let me be > super explicit. You are doing it all wrong! Your most important job as > a software developer is /to communicate/. This gets conflated by the > fact that we have lots of responsibilities at Mozilla. Amongst other > things, I have to know which css selectors are performant, write > robust tests, understand the caldav protocol, know the codenames for > about 8 releases and 20 phones, and /never ever ever use > localStorage/. All of those things come second to communication. > > Good communication takes several forms. Sometimes, it means /writing a > test/ so that you can express to readers and coders (present and > future) what your software is supposed to do. Sometimes it means > estimating the risk associated with introducing a new feature into our > unstable codebases. Below I've compiled a short list of questions we > should all ask ourselves when we file, fix, and review bugs. When we > answer these questions for ourselves, we are /being open/ when we > mirror our answers to bugzilla. > > - Is this a good idea? > - What problem does it solve (and for whom)? > - Is it high priority? > - Are there any risks involved in doing this? > - Who should I ask for input? > - Who should at least know that this is happening? > > Best, > Gareth > > > _______________________________________________ > dev-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
