Websites/Mozilla.org/Archive/Planning: Difference between revisions

Websites/Mozilla.org/Archive/Planning (view source)

Revision as of 07:39, 5 March 2011

2,860 bytes added , 5 March 2011

→‎Coding: New Workflow Plan

GPHemsley

canmove, Confirmed users, Bureaucrats and Sysops emeriti

960

edits

@@ Line 50: / Line 50: @@
 * {{bug|504882|Add RSS feed for Mozilla Foundation Security Advisories}}
 ** Easy to implement if phpSyndication is installed
+=== New Workflow Plan ===
+Presumably our workflow will be at least somewhat superseded by the Mozilla.com/WebDev workflow after the merger, but, depending on when that's scheduled to occur, we should probably come up with a new workflow for Mozilla.org.
+The basic structure would probably be as follows:
+* File a bug
+* Create a patch
+* Get patch reviewed
+* Commit patch to staging
+* Bake patch on staging
+* Commit patch to trunk
+* Mark bug as RESOLVED FIXED
+* Bake patch on trunk
+* Mark bug as VERIFIED
+This is not an especially revolutionary workflow (I believe it's basically what many other sections of the community are using—not sure about WebDev specifically), but it's one that has not been followed much at all for the Mozilla.org codebase. What's especially troublesome is the fact that many patches bypass staging altogether, which makes it very difficult to keep the staging and trunk codebases in sync. In fact, the ideal situation would be to never have to merge ''from'' trunk ''to'' staging—something that happens all too frequently (when somebody remembers to do it, that is).
+==== Reviewers ====
+It's not clear to me who are the active members of the team or what their skills or qualifications are. This isn't a particularly big deal, but it makes it hard to determine who is available (or who is required) to review what patches. I'm OK with simply having us all review each other's patches (just so that each patch has another set of eyes on it before it enters the wild), since there appear to be so few of us, but we should establish that explicitly.
+I also think it's time to reduce our reliance on Reed. He's clearly very busy right now—and even when he's not busy, he's still busy, given all his different responsibilities at Mozilla—and when he's not available, it seems a significant portion of the workflow comes to a grinding halt. Now, I'm not suggesting we banish him from the team or anything ridiculous like that, but, IMO, we can no longer afford to require everything to go through him before it can be completed. (Obviously, not ''everything'' goes through Reed, but a significant portion of the technical stuff does.)
+==== Priorities and Triage ====
+It may be to our advantage make better use of the priority field in Bugzilla. Of the 244 bugs open at the time of this writing, only a handful (~25) have priorities marked. One example of an area that could benefit by getting a default priority might be the bugs generated by the various HTTP error links. To make it even easier, we could just add it to the fields set automatically for the visitor by the link. (There are likely other categories that bugs fall into, but that was the only one off the top of my head.)
+Also, the range of these open bugs goes all the way back to 2001. It's probably time we did some triage to see what was still relevant.
 == Localization ==