Architecture Council/Bugs

Overview

The Architecture Council uses bugzilla as the Repository for all the ideas, discussions or requests that we're dealing with. In many cases, an idea cannot be dealt with immediately; by having them in bugzilla, they don't get lost, they are searchable, they convey all discussions related, and they have a state (NEW, FIXED). The opt-in policy allows for focused discussions among those people who are actually interested in topic, without spamming the others.

At the same time, bugs on bugzilla are the "gateway" by which the entire Community can bring issues before the AC.

As per bug 250763, AC members are encouraged to file a bug for any new ideas to be discussed, rather than sending an E-Mail to the mailing list. As a rule of thumb, any question that we consider of value even after it's answered should go into bugzilla (for archieval purposes) rather than just a plain E-Mail. Questions that we think may be silly or obvious, or that don't have lasting value (such as scheduling a meeting) should go directly on the mailing list.

Getting in Touch

• File a bug for discussion on the EAC, or requesting a mentor. We welcome your input! - See this E-Mail, which was sent to the eclipse.org-committers list in September 2008.
  • SLA: The AC commits to initially answering a request within a week.
  • Escalation: If nobody picks up a bug within a week, or you otherwise feel treated wrong, file a new AC bug with the "Summary" field starting with an [Escalate] tag. The AC leadership will care for it.
• Open bugs: AC Component (closed)
• Open bugs: CC'd to the EAC (closed)

Process and Lifecycle

• Creation: Anybody in the Community can file a bug against the Architecture Council component. New bugs get E-Mailed to the eclipse.org-architecture-council@eclipse.org mailing list automatically. In many cases, AC members may file bugs themselves to spark off discussions.
• Triage and opt-in: Since the bug gets E-Mailed to the mailing list, all AC members will see it automatically. They can now opt-in to the discussion simply by opening the bug (and commenting on it, or just CC'ing). Everybody on the AC is encouraged to look at new incoming bugs at least once a week, although nobody is firmly required to opt-in. If a bug doesn't get an initial answer within that time, the reporter may escalate the situation (see below). During triage, AC members are encouraged to put one of the #Summary Tags on the bug.
  • Discussion: All further discussions on the bug are open for opt-in by those who are interested.
  • Escalation: Since only those AC members who opt-in on a bug actually see the discussions there, it may happen that a bug reporter who doesn't have access to the AC mailing list doesn't feel treated right (such as when a bug isn't been taken care of within a week). He can escalate the situation by filing a new bug with an [Escalate] tag in its summary. The AC Leadership must react to such bugs, since this is the only way how the Community can contact them.
  • Information of Change: At times, the discussion on a bug may take a change in direction that was not obvious by the original description. At these times, those AC members who follow the discussion are encouraged to inform the rest of the AC by sending an E-Mail to the AC mailing list.
  • Moving into #IPZilla: discussions related to IP or legally relevant topics may be moved into #IPZilla. AC members do this by starting the related discussion in IPZilla and cross-referencing the bugzilla and IPZilla items through their URLs.
• Resolving: We should make sure that topics don't remain open forever but get resolved eventually. At the time a bug gets resolved, an automated E-Mail is sent to the mailing list again. There's basically two possibilities for resolving:
  • Moving away into a different bugzilla product or category. Make sure that the AC mailinglist user gets removed from CC in this case.
  • Marking Fixed if a discussion is resolved.

Summary Tags

We use summary tags to group the various kinds of discussions that we are having, such that they can be sorted and grouped in queries and that it's more easily obvious for interested parties what a discussion is really about. Tags are to be put at the beginning of the bugzilla "Summary" field. To date, we have defined the following tags:

• [Escalate] - exclusively used for escalations, see above.
• [org] - anything related to internal organization of the AC work. I had also considered [acorg].
• [mentors] - anything related to mentorship, i.e. Community request for a mentor but also discussions about mentorship.
• [api] - discussions about API in its widest sense, which I'd categorize as the technical interfaces between projects working together.
• [infra] - discussions about Eclipse.org infrastructure in support of better or more efficient development work. Related to [process], could probably be superceded by [process].
• [process] - Discussions about optimizations in the development process, i.e. anything that would make committers work with more fun and more efficiently. Related to [infra].
• [ip] - Discussions related to IP, and Legal questions. Potential candidates for sensitive information to be put into #IPZilla.
• [community] - Discussions about Community Building, or social aspects such as Bugzilla Netiquette and "how to" interact with the Community.
• [microprojects] - Discussions specifically related in support of small projects with few resources. Not sure if we need this.
• [coding] - Discussions, questions or ideas related to actual coding patterns, idioms or best practices - the practical stuff.
• [info] - Discussions about how to better inform the Community-at-large, i.e. publishing EMO or process information.

IPZilla

We use IPZilla as a means for discussions that should not be visible to the whole Internet. We should especially use this for IP/legal questions that we don't want to get exploited by malevolent 3rd parties, or accidentally misinterpreted as incorrect advice before a question is fully resolved. Only the following people can see IPZilla discussions: Project Leads, PMC Members, AC Members and the EMO Legal Team. Specifically Bjorn, Mike and Janet are members of these groups to take care of IPZilla discussions from the Foundation side.

IPZilla Lifecycle

• Creation: Go to The Portal, section "Project Leads: view", then choose pose a question about a general legal issue.
  • If you are initiating the discussion, IPZilla will not E-Mail the architecture council immediately, so you may want to separately send an E-Mail informing the other AC members about the new discussion. You may also decide to file a Bugzilla bug on the AC component to convey the "community aspect" of things while keeping the discussion itself confidential.
  • If the discussion was initiated by a Community bug on bugzilla, an URL into the IPZilla CQ should be put on bugzilla, and the bugzilla URL should be referenced in the IPZilla item. Let bugzilla users know that the discussion is following up in the closed group now, and that they will hear back once the issue is resolved.
  • In the typical case, projects who have ip/legal questions should pose these to their project leads and discuss with their PMCs / Mentors before escalating them to the AC and IPZilla.
• Adding CC's: If you think that a person outside the IPZilla authorized group should be able to see or take part in the discussion, and that person is a Committer, you can put that person on CC of the IPZilla bug and she should be authorized.
• Closing: Again, IPZilla doesn't send E-Mail automatically so you should manually let the other AC members (and perhaps the wider Community) know about the resolution.

Queries

• Currently Open IP Discussions / Closed ones

Improvements

Feel free to edit this Wiki page - AC members are watching this page, so you don't need to be afraid of breaking anything. As an alternative, place comments or ideas on bug 250763 or file a new bug.