Thanks Gareth, for bringing this up -- in a sort of "recursive" form it seems that you communicated very well the bug about the bug process, with a good use case too. After reading your "questions template", at the end, it reminded me on how Bugzilla teach beginners with a basic text templates. A similar thing should be somewhere in the system, so that any level of "beginner" can understand and we can build more value.
The following is what I wrote recently to Robert Nyman, evangelism: "BTW I thought of Hacks/you today as I was watching a thread in dev-platform -- someone said about "759585" and special features from that. The actual bug is not important but I had a sort of a feeling on bugzilla and doors of opportunities or inspiration to people. Here is the case: Some bugs start with a case, links etc, then samples -> testcases. After a patch, there is a landing, and then wanted things come in: MDN, Demos. This is the full cycle. Would be really cool when the full cycle is visible. I know this may not scale - it won't be for all the bugs. However, somehow I felt this could be inspiring to people to, for example, 1) be able to find a demo and trace back to the origins, to the discussions and so. And perhaps 2) some dashboards are the means to make these things happen. Dashboards are coming and going and I think there is something broken about them -- it might be the fact they don't adapt. Would be much better a dashboard to be more like a infograph." For me I think that things such as status board (whiteboard) and votes, are, in a way, a beginning. I always enjoyed bugs with things like: * wanted testcase, wanted MDN docs My pitch is from evangelism view - and I think it's a good case. I keep seeing now bugzilla pages coming up as results in Google -- what used to be Mozillazine results 5 years ago :) This is a change -- bugs could have interpretations into them -- as they are already going towards being exposed. And we could embrace this and, for example, even add bugs to MDN docs. Via improving the exposure, and requesting connection with purpose and abstraction, or visible (think dashboard) priorities, awareness on key communication points would appear. m On Wed, Mar 26, 2014 at 10:54 AM, Tim Chien <[email protected]> wrote: > 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-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia -- www.telasocial.com _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
