| Re: [eclipse.org-architecture-council] Bylaws Change on AC (was: 10-Mar AC meeting notes) |
Martin, I agree with your points. I wasn’t on the call, so I was trying to guess the intent behind the original words posted by Wayne. But I was wondering as I wrote the words how much influence the AC really has over any project’s architectural choices. Should we remove the reference to “influence” entirely? Or do you have another suggestion on the wording? From: Oberhuber, Martin [mailto:Martin.Oberhuber@xxxxxxxxxxxxx] Hi Mike, “influence software architectures used by Projects” was not my original intent when discussing the rewording on the call. In fact I’m not sure to what extent the AC can influence the architecture used by a project. Such architecture is typically dictated by things like what pre-existing code can be re-used, what 3rd party libs are at disposal, what are the goals to reach and who’s going to do the work. Essentially, the project’s architecture is made up by the projects (or the leading companies in there), with constraints set up by the EMO through the IP process. Often the AC won’t even be notified about architectural changes. At the very best, the AC can give guidance here through Mentoring, or maybe through offering “Architectural Reviews” like Mik has proposed at some point in the past. But at any rate, as Wayne said it will be a “pull” scheme rather than “push” unless explicitly enforced by the EDP. I wanted to highlight a different aspect / responsibility of the AC. 1. It is important that the AC exists and does have a formal role. If we admit that _everything_ is up to the Community we admit we have chaos. That’s not what we should have. The AC is constrained by the “Tragedy of the Commons” problem but that doesn’t mean we should stop running. Having the AC role well described in the Bylaws is one important ingredient of making it interesting for individuals to step up and invest some time, thus breaking the “Tradegy of the Commons” problem. 2. I deeply believe in Conway’s Law [1] which basically says that our software architectures are a copy of our organizational structures. So if we want to influence our architecture we need to look at our processes. An in fact the AC _has_ been involved in setting up guidelines, processes and practices in the past. Just think about git, Hudson, bugzilla, libs updating policy, mailinglists, maven, … the AC has had a word in many of these, and often is the first address to ask for advice when an individual or a company wants to set up guidelines or processes. The processes and tools that we use influence our code and architectural quality. One might claim that this aspect is covered by the “responsible for the EDP” section but I don’t think that’s sufficient. It’s not about formal process only, but also informal guidelines, best practices and tools… having a body that can be approached. To me, the AC is essentially “the eyes and ears of the Board”, monitoring and influencing the Eclipse Community and our Processes, thus responsible for the Architecture of Eclipse as a whole. I’m not yet sure how to best mold this into words suitable for the Bylaws. [1] http://en.wikipedia.org/wiki/Conways_Law Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich All, When I went to paste the proposed revision into the Bylaws, I found it a little ambiguous in places. Remember that the Bylaws need to be very clearly worded and are modified very infrequently. How does this work? The Eclipse Management Organization shall establish an Architecture Council responsible for: (i) project mentoring, (ii) monitoring of, guidance on, and influence over the software architectures used by Projects, and (iii) maintaining and revising the Eclipse Development Process subject to the approval of the Board under Section 3.9(c). The reference to Section 3.9(c) is necessary to reflect the fact the Board has final approval of any revisions made to the EDP. |