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-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
