I think "point of contact" is fine.
I'll take the blame for the word "Chair" - as we were discussing
some of the issues Silona mentioned in her original email (and
which we could have gone into more detail about - again I'll take
the blame as I believed it was urgent to get the TSC talking about
this) I noted that our WGs and SIGs have Chairs, so we thought it
would be simpler if we used the same term for someone who would
perform roughly the same function. Also, I have a tendency to
borrow and steal from the Apache community structure whenever
possible, and this is not unlike the "PMC Chair" that each project
there has.
To compound it, we used the term
"project manager", which in common parlance suggests a
Gantt-chart-weilding, time-boxing slave driver who manages
releases and punishes the lazy. :) Clearly that's not what was
intended here. A "Chair" on the WG or SIG or even here on the TSC
is really there to remind the community of its processes,
policies, and commitments to the rest of the Hyperledger
organization. The Community Architecture team Silona leads is so
often on the hook for the grunt work of implementing things that
make this community cohere, so it was out of a desire for
simplicity that this proposal is made. And her jerk of a boss,
me, asks her and her team to constantly be thinking about "scale",
so that our fixed headcount doesn't become an unfair limiter on
the ability for the TSC to approve a worthy new project, and to
avoid feeling like we have to do ourselves what we could turn to
motivated volunteers in the community to do.
In that light, to review the short list
of proposed responsibilities:
* Writing and giving Quarterly
Updates to the TSC, and attending TSC calls, especially when
presenting the Update.
Clearly, as Hart suggested, this could
be delegated - making sure someone writes this is the key thing to
oversee, not to write it themselves. And a good Chair & Vice
Chair would rotate it around anyways.
* Be the primary interface with the
Hyperledger staff in regards to informing the project participants
and contributors about ongoing Hyperledger activities,
commitments, and cross-project initiatives
As the volume of such communications
has grown, there's hesitancy to distract the full developer
community for each request for speakers for an event, or help
looking into DCO conformance issues, or understanding something
sensitive regarding individuals on a team, or other things that
could trigger more noise than necessary. We will tend to
overshare rather than undershare; still, it's nice to know that if
we need to reach out to Hyperledger Foobar, the context switch
cost can be mitigated by having one or two individuals for her
team to go to first. Might also be helpful between projects.
* Keeping the list of active
maintainers current.
As Chris suggests, maybe there is
already a process for this within a project, and a systematic way
to maintain that e.g. MAINTAINERS.md. Great. This is just to
ensure there's a human backstop to a process that could vary
widely project to project, or if the TSC decides to standardize
those actions more across projects, to implement that standard.
A proper Chair, of any of our units of
community, would be wise to view themselves as servants of the
community they are attached to, and not as top-down lord. I think
we took that for granted in the proposal. So long as those three
obligations seem right, POC seems fine.
Let's discuss more tomorrow on the TSC
call,
Brian
I
think this is the right idea. We can even generalize this
system and have a project “point of contact for X” where X
could be security, quarterly reporting, press releases,
etc.
Most
(or all) of the projects already have effective project
management, so I think there would be quite a bit of
resistance (as some have already indicated) to mandating a
new type of project governance. But having a top-level
“point-of-contact.md” that functions as a list of contacts
for a project for various different things might be a nice
thing to have. I wouldn’t be opposed if the TSC mandated
to the projects, “give us at least two emails for security
concerns, give us at least two more for marketing,” etc.
Such an approach might solve the problems that Silona is
looking to fix while also not disrupting the current
governance structure.
Thoughts?
Thanks for your time.
Thanks,
Hart
From:
tsc@... [mailto:tsc@...]
On Behalf Of Dave Huseby
Sent: Tuesday, June 18, 2019 9:10 AM
To: Mic Bowman <cmickeyb@...>
Cc: Shawn Amundson <amundson@...>; Dan
O'Prey <dan@...>; Silona Bonewald
<sbonewald@...>; Hyperledger List
<tsc@...>
Subject: Re: [Hyperledger TSC] Chair and Vice Chairs
for Projects
I want to point out that for the last
two years, I have maintained a list of "security
volunteers" that are "points of contact" in each project
that are also on the
security@...
mailing list. I try to keep at least two people on each
team so that there is a backup person if the primary
person isn't around. The design is to keep all projects in
the loop on confidential security bug reports and to have
people who can coordinate the fix for security bugs on an
urgent basis if needed. It has worked well so far but I
would like to tighten it up a bit and have more regular
check-ins with people to make sure that each team has
somebody.
I like Silona's proposal because I
think it functions the same way as the security volunteers
but for other community related needs like the TSC updates
and coordinating other community upkeep. I don't really
care what title we use so long as the duties are clearly
written down. I want to add the security volunteers to
this effort with the hope that it will all coalesce around
a directory somewhere on the wiki that let's everybody
quickly figure out who to talk to.
On Tue, Jun 18, 2019 at 8:56 AM Mic
Bowman <cmickeyb@...> wrote:
Agreed that the name "chair" implies
more than what is actually intended. "Point of contact"
seems more appropriate.
Regarding the rotating TSC
updates... i think there is a difference between who
actually handles the TSC update & who ensures that
*someone* handles the TSC update. While this doesn't
seem to be an issue with the larger, active projects,
I can imagine that it is more of an issue with some of
the less active projects.
On Tue, Jun 18, 2019 at 4:47 AM
Shawn Amundson <amundson@...>
wrote:
It would be better to call
these "points of contact", as to not confuse it
with a decision-making capability. Within some of
the projects, we have a team of long-term
maintainers for decision making, but no 'king of
the project' position, intentionally. The points
of contact should probably not have a primary if
there are only two.
The maintainers lists,
similarly, are governed by specific rules within
the project. We are currently in the process of
updating these for Sawtooth and it will require a
fair bit of maintainer voting.
For the TSC updates, we've been
trying to rotate that around the community a bit
so that it's not always the same person
representing the project.
For the MC, I think the TSC
should appoint maintainers to the MC to
participate as advisors directly, with the intent
of wide project coverage.
Unofficial +1, this would be
very helpful from the marketing side too
On Tue, Jun 18, 2019, 06:14
Silona Bonewald <sbonewald@...>
wrote:
I would like all
projects to either elect or have the TSC
nominate Chairs and Vice Chairs. The
Chairs would serve more of a project
manager role within the project's
community.
The CA team is seeing
that larger projects that have many
diverse repos and having Maintainers be
responsible doesn't scale. There is often
confusion on who to speak with.
The CA team believes we
need this type of role to help us scale to
support more projects for the community.
The Chair's
responsibilities would be:
-
Writing and giving Quarterly Updates to
the TSC, and attending TSC calls,
especially when presenting the Update.
-
Be the primary interface with the
Hyperledger staff in regards to informing
the project participants and contributors
about ongoing Hyperledger activities,
commitments, and cross-project initiatives
-
Keeping the list of active maintainers
current.
We would like Vice
Chairs to be available for when Chairs are
not available esp on the larger projects.
We can scale this out
gradually and not require every project to
do this at first but we would like a
deadline perhaps in 3 months time? We
would also like this to be a part of the
project proposal process at the beginning.
This would require a
vote of the TSC.
--
This
message, and any attachments, is for the
intended recipient(s) only, may contain
information that is privileged, confidential
and/or proprietary and subject to important
terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html.
If you are not the intended recipient, please
delete this message.
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf
