Formalize stakeholder roles in working group charters

Could you point to a concrete example of this maybe so we could see what you have in mind? I am not familiar with the terminology you are using.

I think I see where you're coming from on this ... however, I am curious as to whether the stakeholder list will vary enough from charter to charter to provide value at this particular level of the hierarchy; or simply boils up to become the global "Drupal community" as consulted and informed for each charter.

To illustrate, the role of the Community Working Group (CWG) is largely one of assisting the community with conflict resolution ... but the conflicts they get involved in could arise from within (or between) any of the stakeholder groups identified. Likewise, the Technical Working Group is primarily a policy body, but the policies they maintain will span a wide variety of stakeholder groups, with varying levels of stakeholder interest based on the actual policy.

That said, where I do see some value in the suggestion is if it were applied one level down the chain, internally within the given working groups as desired. As an example, identifying the stakeholders and RACI accountabilities for an individual policy maintained by the Technical Working Group can help define the scope, intent, and execution of that particular policy. Likewise, the breadth of activities performed at the overall working group level for the infrastructure or content working group would dilute the results of such an exercise ... but applying it specifically to the 'git infrastructure' or 'drupal.org marketplace' allows for more precise (and thus more valuable) output.

From a representation perspective, my understanding is that the CWG and TWG (at least) are intended as small dedicated teams, rather than large committees; and I'm assuming the same for the other working group bodies. At the same time, the range of potential stakeholders for many of these groups is so wide that it is impossible to achieve full representation given the size of the working group. In the end, if a stakeholder group feels that they are not being properly considered or represented through the activities of a particular working group, then an escalation channel exists for them to take that concern to either Dries or the DA (i.e. the appropriate body overseeing that working group).

I kind of agree with jthorson here. Mentioning that WGs work with the Drupal community and keep it informed seems enough to me. I don't think we need to define detailed lists of groups in each charter.
Particularly for the Content WG example - we already say that each of D.o WGs works closely with the DA and other D.o WGs (including infrastructure), so these 2 are already covered. The content team - I see content team as an extension of the Content WG, or in other words Content WG is a part of a larger Content team, which is empowered to make (strategic) decisions. So it goes without saying that Content WG will consult/inform content team. And 'site users in general' can be covered as 'Drupal community'.

What we might want to do is make a list of key stakeholders who absolutely need to have a representative in the WG. For example:
- each of D.o WGs must include at least one Drupal Association staff member
- to ensure that all D.o WGs work in sync 1 member (chair?) of the Content WG and 1 member (chair?) of the Infrastructure WG must be members of the Software WG.

I agree with LeeHunter's proposal for having a documented Roles and Responsibilities in each charter (a RACI chart is good standard way of doing that).

Most of the Municipalities and Universities that I have done consulting work for document the following in the charters for their Committees and Working groups (much of it public).

1. constituency
2. term
3. meeting schedule
4. nomination process
5. appointment process

This is in addition to the obvious purpose, duties, etc. For instance one of the Working groups might be made up of (constituency) an Association Rep, a Community Rep, and a Representative from the other WG. Terms might be for 2 years and setup to be so that only half the members change at any time. For us the nomination process might involve an open process of submitting names, and the appointment process might consist of having the Board Executive select from among the nominees.

HI all -

It's governance day for me here at the DA. I'm working on figuring out how was actually make these committees work very tactically and get that together in a proposal that will complement the charter. I see the charters as akin to a constitution - purposefully broad - so that we have the latitude to redefine the specifics of how these groups work as needed, without having to go back to the board each time to update the charter.

I'm working on those more detailed process recommendations today, then need to review with staff and board. When we have something that we are internally comfortable, we will share here as well. I mention this because I think that this part of the work will address al lot of the very valid and smart points above. This will be where we get into the meat of how these groups will work.

After I get through some drafting today, I'll get a blog post up next week with some next steps.

In them meantime, please keep your very specific thoughts and recommendations coming. These are helping my draft immensely!

Best,
Holly

@holly.ross.drupal here's some of my personal opinions ... hopefully it's timely and on topic:

• Definitely keep the Charters being fairly broad and make sure that everyone understands that this is a "governance" process and not the process for how the committees work .. i.e. creating a framework of checks and balances etc. not dictating day to day behavior of the committee
• Ideally more detailed process recommendations shouldn't be needed ... create a nice governance framework then let the committees run themselves; a mixed metaphor: if there's a good API and it doesn't take too long to respond, I don't care what happens under the hood
• These committees are suppose to represent diverse stakeholders, so:
  • There needs to be some minimal form of communications, Minutes are an easy way to make this happen, but any view into how the decisions are being made works (issue queues per committee could even work)
  • People need to know who is representing them: for instance I am an institutional user of Drupal, a bunch of Names of high profile Drupal contributors from the big Consulting shops don't necessarily represent my needs ... I appreciate these project members' efforts but I don't necessarily see them as representing "me"; yet the same list of names but with roles like "DA Rep", "Project Rep", "Comunittee Rep." would let me know that someone on the committee is looking out for me. For the project committies "Dev Rep", "User Rep", "Site Builder Rep" might be the type of reps
• try to make it clear which committees are DA committees and which are project committees
• The Drupal Association should consider formally adding a board "executive" (President and two others) for the DA Committees to report to, these aren't board committees so they shouldn't have to report to the board (cuts a bunch of process out)

Hopefully I'm not making this more complicated then it needs to be.

I just spent a bit of time reviewing the latest verions of the charters.

And I think @LeeHunter had it right, what's needed is to "Formalize stakeholder roles in working group charters". Don't put in specific members but put in who is represented and how often they get nominated/selected. (you can ignore my other comments as off topic rambling opinions).

I actually found this particular part of your rambling very interesting and important:

I appreciate these project members' efforts but I don't necessarily see them as representing "me"; yet the same list of names but with roles like "DA Rep", "Project Rep", "Comunittee Rep."
[...]
"Dev Rep", "User Rep", "Site Builder Rep" might be [another] type of reps

I feel an increasing need for this level of transparency.

Back in time during D7 core code freeze, we even had an intense discussion on the question by which actual and indirect stakeholders Drupal core development was and is actually influenced. The results of that exercise weren't exactly fruitful (i.e., no surprises, no effects), but yet, the results were and still are very interesting to see:
https://docs.google.com/spreadsheet/ccc?key=0Apy-l9aX_Tf5dEZuVDA3QjhjS2V...

And, in the end, that's literally all that Transparency is about: Show it to me.

For explicitly nominated committees, it is immensely important to clarify which party represents whose interests.

That said, I have sufficient trust in all governance committee members to be schizophrenic enough to not only represent their own/direct interests, but always think of underrepresented parties, too. But in the end, when it ultimately comes to decision-making, I'm relatively sure that no one will deny that someone's direct/primary interests will influence decisions. We're humans after all.

I'm not yet sure what the take-away is, but I think I'm able to +1 the general idea of "transparent representatives".

I like the intention of what sun and others are saying here about having specific roles for who you're supposed to represent.

However, I don't think it makes sense to have specific roles/delegates on these committees that are tied to representing the interests of specific stakeholders. When it comes down to it, I want people on these committee who are reasonable, fair, good listeners and communicators, who can see things from many angles, and who will take the democratic process seriously. The only point of democracy is when there's a question as to what's the right answer. You don't need democracy or transparency to arrive at a decision about what timezone Oakland is in. You only need democracy and transparency when there's doubt as to what's right. Yes, in that situation, it's good if a lot of different perspectives are available, but ultimately, I want people on these committees who can take lots of different inputs, do pattern recognition and synthesize a perspective, clearly articulate that perspective, listen to other (perhaps differing) perspectives then their own, weigh all the "evidence" or information, and given everything, make a decision as to what they think is right. Their vote on a given question might not be what the stakeholders they're supposedly representing would have said, because when presented with all the info and a coherent argument, they changed their mind, or decided that "their stakeholders" should compromise for the greater good. So they (and the rest of the committee) gets to explain their process, why they voted the way they did, and either convince the stakeholders it was the right thing, or discredit themselves and begin the process of being replaced as members of the committee.

The primary abilities for the people on these committees should be:
A) To listen (even from people who suck at communicating but actually have something useful to say if you can find it)
B) To think clearly, even in a heated or difficult environment
C) To find balance and compromise when needed
D) To formulate and articulate a perspective/argument about what's right
E) To communicate effectively

I'm less concerned about specific stakeholder roles getting "seats at the table" than I am about having a table full of people who listen well.

I think it's important to have clear list of types of stakeholders in various spheres of the Drupal universe (the community, the code, d.o, etc) but I'm opposed to trying to enumerate a list of stakeholder delegates that each committee is supposed to be composed of. Do we need to change the charters every time a new kind of stakeholder materializes? Do we need a separate delegate for each stakeholder "community"? If not, why do some stakeholders get "representation" and others don't?

I'd rather have a small committee of good listeners and communicators who can synthesize what all the different herds of cats are screaming about than a large committee that somehow tries to represent all possible viewpoints internally.

Agreed with everything in #12. I'm just thrown off by the title of this issue being "Formalize stakeholder roles in working group charters", as if each (some?) stakeholders are "roles" in the working groups.

If the point of this issue is: "Document which stakeholders each working group should talk to" -- +1. I'm just -1 to saying that there are roles in each working group for each/some stakeholder groups.

Is that distinction clear?

Thanks,
-Derek

Updated issue summary with link to https://en.wikipedia.org/wiki/Responsibility_assignment_matrix