Thanks Gareth, I will take this to the team tomorrow. On Wed, Mar 26, 2014 at 9:09 PM, Gareth Aye <[email protected]> wrote: > 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. > > 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 >
-- Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox OS, Mozilla Corp. (Taiwan) _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
