Non-member proposals and subcommittee interaction #140
Comments
|
Thanks @wking @ctb for raising this issue. As you suggested, there's always room for improvement in communications, and it's an important part of any organization, especially one as community engaged as our's. Good communication is something we're committed to, and you can see some of our work on that with the new 'announce' list, our community calls, monthly newsletter, our assessment efforts (where we've published the report with DOI and all the data), publishing all our talks and subcommittee and Steering Committee reports (although we need to be sure to get these out in a timely manner). Data Carpentry is also focusing more on our blog and updating it with activities, something that our Associate Director is taking leadership on now that she's back from parental leave. The next thing we're working on are these more informal modes of discussion around ongoing activities that you mention. One of the other challenges there is the distribution of information across websites, Google docs, Github issues, email lists, personal email threads, blog posts, Slack and Twitter. It's a challenge for both the posters and communicators of information and the people who are interested in the information. It's a challenge not easily solved because members of the community have different preferences and needs for the way they look for and receive information. For instance, for the CoC subcommittee, they were updating the Google doc where they'd asked for comments, and switched over to that mode of communication, but then we didn't come back to the github issues. It's naive to think a technical solution can solve all the things, but something that might be useful to think about is an aggregated 'updates' website and RSS feed that would put all of those updates in one place. Admittedly that would mean that it was all the updates and not the updates on a specific topic, but the top of the updates page could provide links to the different initiatives, so people could find information there. So there would be a 'push' component where people could get all the updates by just subscribing and 'pull' component where people could seek out information on the topics they're interested in. We'd be happy to hear suggestions both technical and social around communications. We know we're not there yet, and we make mistakes, but our goal is to operate as transparently as possible with broad community engagement. |
|
On Thu, Nov 17, 2016 at 04:25:34PM -0800, Tracy Teal wrote:
I think this sort of organic ecosystem is great, and folks can have
Combining this with your bridge reference from 4 turned up And it would have been nice to have a ping in either that issue or in
This sounds like a reasonable funnel channel to me. Folks following The drawback is that this approach gives two one-way pipes, a Using an issue/PR tracker (or blog with open comments, or whatever), If an issue tracker (or blog with open comments, or whatever) is too
You'd just have:
[3]: Does Data Carpentry have a public issue tracker for their |
|
So, I think all of this stems from some confusion based on an expectation that the During this time Data Carpentry hired @ErinBecker who devoted tremendous time to gathering and synthesizing community input and developed the draft document that was sent around for community comment with the thread on the issue staying dormant. A subcommittee was formed, with an open call to the community for participation, that subcommittee took ownership of the document and process, incorporating community feedback and inputs. So there are a few things to unpack here:
The mentoring committee has been the best example of a subcommittee providing regular updates to their activities. They use etherpads for their meetings and then export the etherpad to markdown after the meeting. Much of this comes down to the practicalities of tooling, so any guidance should be abstracted away from specific tools and make recommendations for subcommittees to work in the open, and provide regular updates to the larger community about how they can stay abreast of and/or participate in the activities. I am committed to find ways that that reporting can be aggregated so we can share it via our newsletter and websites. |
|
@jduckles, this seems like a pretty clear summary - thanks! I appreciate
your commitment to clear communication channels.
From my perspective, I am simply unable to participate in scheduled meetings
and phone calls and committee work most of the time. I am reconciled to
the notion that this will leave me out of decision making and input loops
most of the time, as I have more than enough committees to serve on, meetings
to attend, and phone calls to take as part of my job ;).
With respect to online communities, for me the only solution that has stuck is
GitHub, which has fairly granular permissions, notification settings and issue
tracking, and maintains a reasonably permanent record of things.
This is not just me -- it's a solution adopted by many async teams (see Max
Ogden's excellent articulation (https://github.com/maxogden/async-team).
It is also a solution that comes closest to meeting my aspirations of open
community development for the carpentries moving forward; I hope that committee
reporting and interaction suggestions can be designed with that openness and
potential for community interaction in mind.
|
|
On Wed, Nov 30, 2016 at 07:37:53AM -0800, Jonah Duckles wrote:
From my understanding (and admittedly I wasn't around during the
formation of these repos) this repository's primary aim was to be
the canonical source for board policies, procedures and minutes.
I think this is *why* the GitHub repo is such a good venue for raising
actionable issues to the board. E.g. in #6, I proposed a change to
the committee roles, and everyone can see exactly what I was
suggesting. The difficulty is that some board-driven actions are not
managed by this repository (e.g. the code of conduct, whose canonical
source is… [1,2,3]? [4,5,6]? Somewhere in [7]? Even in those cases,
there was still presumably a motion put before the board (like [8]).
In cases where the content of the motion is not sensitive (everything
that shows up in the public minutes?), having an issue in this repo
with the self-contained motion or a link to more detail (e.g. [9])
would give non-members time to provide feedback which the board could
take into consideration (although they're obviously still free to
resolve motions as they see fit regardless of public feedback).
There has not been an explicit workflow to track GitHub issues from
the community and raise them with the board at board meetings. There
was clearly an expectation by @ctb and @wking that this would be the
case.
There are two things going on here. One is “how do non-members
propose changes?”. Issues here have been a good way to do that in the
past (even in this case, where the discussion from #114 ended up
informing the eventual decision). If some issues / PRs here stay open
for a few months, that's how open teams work ;). Everyone's busy, and
some proposals don't seem particularly exciting/pressing. I'm fine
with this side of things.
The other side is “how do non-members stay abreast of pending board
activity to provide feedback before action is taken?”. This is the
part where we need to clarify the expected workflow. With #114, there
was very clearly a subcommittee forming [10]. What was less clear (to
me anyway), was that the subcommittee would reach a conclusion and
send it straight to the board without returning to #114 with a “the
subcommittee has settled on $RESULT and will propose $MOTION to the
SWC/DC boards at next week's meeting. Does anyone have any final
feedback?” or some such. I think the CoC changes are pretty solid,
but nothing springs into being perfectly formed (e.g. the typo fixed
by swcarpentry/website@df00bc40, and the discrepancy in who gets
contacted before a resolution is enacted [11,12]). Having a final
round of public review before the vote will avoid some of those.
The discussions in question were largely that, discussions, with
actionable items buried within them. I recommend we use something
like issue templates at GitHub to help shape this in the future.
Issue templates are good at providing some structure, but I think the
distinction between discussion and actionable items is rarely clear
enough to be the basis for distinct workflows. I certainly make lots
of proposals that I feel are pretty cut and dried, but review turns up
all sorts of holes that need to be addressed, and sometimes the thing
I originally thought was obviously right ends up getting scrapped
entirely ;). When folks *know* something is in the discussion stage,
they can discuss it wherever they like. Some kind of ping “we're
having a discussion about $THING in $CHANNEL” would be nice. Maybe
via discuss@? Or a blog post? Or an issue in this repo? A policy
suggestion like “if you expect an extended discussion on an issue,
post a note to $FEED” would help the community keep track of what's
going on, so they could jump in on issues that struck their fancy
before discussion got too far along.
Once the discussion settled down into a consensus though, it would be
nice if that consensus made its way back into an issue or PR here
before the board voted it in. Obviously some things are private or
time-sensitive (so we shouldn't *require* proposals to be floated here
first), but in most cases the more public review something gets before
the board picks it up, the less work the board has to do on its own
;).
2. We have a mix of tools that are used, making any RSS feed or
tracking difficult. Google Docs, GitHub, Etherpads are all tools
actively used by subcommittees and the Steering Committee itself.
A diveristy of discussion tools is not a problem. I'm just advocating
for more ways to hook folks into those external discussions.
Following discussion in those tools is possible, but it's hard if you
don't know if/where that discussion is going on ;).
3. Perhaps @wking and @ctb can make recommendations and develop
guidance for @swcarpentry/board that can be rolled out as part of
how we aspire for committees and task forces to operate and
communicate with the community at large.
I'm happy to work up a PR with more formal language, but would like to
see which of the available choices sounds the most appealing first.
Summarzing this thread so far, choices are:
# Submitting issues
a. Using issues/PRs in this repo.
b. Providing suggestion boxes on the carpentry websites [13].
# Learning of new discussions
Post notices about new subcommittees or other discussion efforts to:
a. discuss@
b. this repo
c. https://software-carpentry.org/blog/
# Staying abreast of current discussions
## Fast/raw updates
Once it forms and picks an internal discussion channel (e.g. a Google
Doc), have the subcommittee post directions to that channel to:
a. this repository
b. discuss@
c. the blog
d. nowhere public
## Delayed/curated updates
Have the subcommittee post periodic updates to:
a. this repository
b. discuss@
c. the blog
d. nowhere public
With (d) for both raw and curated updates, the only way to be a part
of the discussion is to join the subcommittee. I'm with @ctb in the
“unlikely to be able to commit to anything synchronous” camp. So
(a–c) vs. (d) is balancing “how easy is publishing the raw channel or
curated updates?” against “how much do we care about asynchronous
contribution?”.
# Staying abreast of pending actions
Post notices of planned motions for final comments to:
a. this repository as PRs, where accepting/rejecting a motion is
merging/closing the PR.
b. discuss@
c. nowhere public
I've ranked each of those roughly by descending preference (I like (a)
more than (b), etc.), but I'm not driving this thing ;). And they're
not all mutally exclusive (e.g. the CoC subcommittee hit the “learning
of new discussions” ball out of the park [10,14,15]). So I'd like to
hear from our leaders which choices sound most tenable to them, and
then I'll write up whatever my most-favorite-but-not-immediately-
rejected option is ;). And if folks want to put other options on the
table or re-frame the whole issue, that's fine with me too ;).
[1]: https://github.com/swcarpentry/website/blob/df00bc4002393f487b6ce1f47373faaa04f5285f/pages/conduct.md
[2]: https://github.com/swcarpentry/website/blob/df00bc4002393f487b6ce1f47373faaa04f5285f/pages/CoC-reporting.md
[3]: https://github.com/swcarpentry/website/blob/df00bc4002393f487b6ce1f47373faaa04f5285f/pages/CoC-enforcement.md
[4]: https://github.com/datacarpentry/datacarpentry.github.io/blob/a5e80394b2fc15f7fa6173be4ec60ddbb3ef35ad/pages/code-of-conduct.md
[5]: https://github.com/datacarpentry/datacarpentry.github.io/blob/a5e80394b2fc15f7fa6173be4ec60ddbb3ef35ad/pages/CoC-reporting.md
[6]: https://github.com/datacarpentry/datacarpentry.github.io/blob/a5e80394b2fc15f7fa6173be4ec60ddbb3ef35ad/pages/CoC-enforcement.md
[7]: https://github.com/carpentries/bridge
[8]: https://github.com/swcarpentry/board/blob/master/minutes/minutes-2016-11-02.md#motions
[9]: https://gvwilson.github.io/career-advice/
[10]: #114 (comment)
[11]: https://github.com/swcarpentry/website/blame/df00bc4002393f487b6ce1f47373faaa04f5285f/pages/CoC-enforcement.md#L70
[12]: https://github.com/swcarpentry/website/blame/df00bc4002393f487b6ce1f47373faaa04f5285f/pages/CoC-reporting.md#L62
[13]: #141 (comment)
[14]: http://lists.software-carpentry.org/pipermail/discuss/2016-August/004663.html
[15]: https://software-carpentry.org/blog/2016/08/code-of-conduct.html
|
|
Wow, @wking, thanks for the thorough workup! I am pinging @k8hertweck @raynamharris @JasonJWilliamsNY @BillMills @weaverbel and @rgaiacs here, I think that all of us should do a think on this. |
|
This is a very long thread and I need more time to review thoroughly, thanks @wking . At first glance, I think this is an area that the position of secretary on the Steering Committee could be shaped in a way that make the SC more transparent and facilitates communication between the SC and any other subcommittee. If I am getting this right, is there an opportunity to implement the draft plan I see forming? |
|
Thanks @wking! You bring up some very important points. It is difficult to wrangle all the information that comes from a variety of channels (blue jeans discussions, ether pads, issues, PRs, private and public google docs, blogs posts, tweets, emails, etc). Like @JasonJWilliamsNY my first thought that this could be shaped into a more formal definition of the secretary. It could also fall into the hands of someone who job description (in part) is community communication. Or maybe we can distribute the responsibility a little more and each of us agree to a certain amount of increased communication and work towards better linking progress back to original discussions. I'll keep thinking about this. |
|
On Tue, Dec 06, 2016 at 02:53:06PM -0800, Jason Williams wrote:
At first glance, I think this is an area that the position of
secretary on the Steering Committee could be shaped in a way that
make the SC more transparent and facilitates communication between
the SC and any other subcommittee.
I assume the steering committee ↔ subcommittee communication is fine.
Although when I went to dig up a link to the steering committee
liasons embedded in subcommittees, the only hits I found were in the
mentoring minutes [1], so I assume liasons are optional.
The issue I'm trying to address here is (sub)committee ↔ non-member
communication. I'm hesitant about putting *all* of this on one
person, since there's a lot of communication going on.
With the classification from [2], I'd break down responsibilities as
follows:
# Monitoring issue submissions
The steering committee secretary watches wherever these come in for
new submissions, but there is no guaranteed turn-around time and other
folks are welcome to pitch in (assuming they have access to the
submission channel).
On the GitHub issue vs. suggestion bo front, I just noticed that we
already recommend swcarpentry/board issues as a way to propose new
subcommittees and task forces [3].
# Advertising new discussions
The discussion initiators are responsible for advertising the new
discussion.
I expect this is usually a chicken/egg thing, with an initiator
wanting to open a new channel (mailing list, subcommittee, task force,
Git repository, motion PR, …), then participants accumulate as the
idea gains steam [4], and at some point the steering committee
green-lights the idea [5]. Anyone involved in the initiative should
be allowed to advertise it at any stage in this process, with some
advertisements going out early (“we're going to propose a CoC
subcommittee, who wants to be on the ticket? Interested parties can
follow along in this Google Doc [link]”) and some going out late (“the
steering committee has formed a CarpentryCon Task Force. Interested
parties can follow along in this Google Doc [link]”). I'm fine with
either (except for proposed motions, more on this later).
# Publishing current discussions
The members of the initiative are responsible for this. If the
steering committee thinks they are handling it poorly, they can give
advice and, in extreme cases, disband the initiative. So the buck
stops with the steering committee, but in most cases they won't be
doing much of the actual work.
# Publishing pending motions
The steering committee member proposing a motion is responsible for
having it published with a sufficient time for review. The chair is
responsible for checking and enforcing these rules, although the
sponsor, secretary, or really anyone, can make the chair's life easier
by collecting an agenda in advance of the meeting with notes about all
pending motions and where/when they were published for review.
Of course, all of this talk about responsibilities is a bit fuzzy
without more clarity on what is required ;). For example, if the
consensus is that (c, nowhere public) is the desired channel for
pending motions, then nobody has any responsibilities around that.
[1]: https://github.com/swcarpentry/board/search?utf8=%E2%9C%93&q=liason
[2]: #140 (comment)
[3]: https://github.com/swcarpentry/board/blob/e439ea9f4f065a9698dc0e4bab1fcb803875a692/subcommittees/proposal_instructions.md#step-3-submit-an-issue
[4]: https://github.com/swcarpentry/board/blob/e439ea9f4f065a9698dc0e4bab1fcb803875a692/subcommittees/proposal_instructions.md#step-2-draft-a-plan
[5]: https://github.com/swcarpentry/board/blob/e439ea9f4f065a9698dc0e4bab1fcb803875a692/subcommittees/proposal_instructions.md#step-4-proposal-review-revision-and-approval
|
|
Ah okay @wking . I see now the distinction about communication across levels (committee ↔ subcommittee ↔ subcommittee) and some of the breakpoints in communication. I think I have some ideas/thoughts but I need to think them over. |
|
I am really excited to see this discussion developing, as managing community input + formation of a consensus has been an increasingly pressing issue across several parts of the Carpentries over the last year or so. Now that we have a basic framework for how things function (which, frankly, may have been developed in what seemed like a black box out of sheer necessity), I feel like we're ready to move towards a more transparent, inclusive discussion on how decision-making can and should occur. I'm eager to give @wking's suggested model of communication a test run in the next week as I submit a proposal for a new subcommittee (Lesson Infrastructure) as split from Lesson Maintainers (which will require a corresponding revision of subcommittee goals/scope). This plan was announced in a blog post, but given I did not receive any feedback at the time, it's clear that mode of communication was insufficient. As I've discovered through my interactions with the lesson maintainers, it can be a real struggle to feel like a consensus is being reached around important community issues. I hope we'll all keep in mind the need to balance community interaction and input with a need for practical, continued improvement. |
|
I think this is an important discussion and one that goes beyond the question of what specific policies/procedures should be for formalizing interactions between the community and SWC/DC steering committees and subcommittees. To my mind this question should be part of a broader conversation about how we (staff and committee members) facilitate interactions among all members of our community. We'd like to think broadly about this question and invite thoughts and suggestions from community members in helping to shape our overall communication strategy. We've started a new repository here to get community input as we move forward in thinking about our strategy. That channel will be monitored by Carpentry staff and will host communications-related decisions as they are developed with the input of the community. |
|
On Mon, Dec 12, 2016 at 03:44:31PM -0800, Erin Becker wrote:
I think this is an important discussion and one that goes beyond the
question of what specific policies/procedures should be for
formalizing interactions between the community and SWC/DC steering
committees and subcommittees. To my mind this question should be
part of a broader conversation about how we (staff and committee
members) facilitate interactions among all members of our community.
There is certainly a benefit to consolidating discussion when you can
achieve that. However, the Steering Committee, Subcommittees, and
Task-Forces are much more structured entities than carpentry
communication as a whole. For example, a policy around publishing
planned motions for final comments [1] can be worked into this
repository fairly cleanly. Something like:
File a PR with the wording of your proposed motion at least a week
before the meeting where it will be proposed. For motions that must
be made quickly or in secret, the Chair may waive this requirement.
When the requirement is waved, the waving and brief motivation
behind it must be recorded in the public minutes.
That fist into “SWC Steering Committee activity revolves around
swcarpentry/board” pretty clearly, but is not as good a match for “SWC
Steering Committee activity revolves around carpentries/conversations”.
So I think we still want something like the framework I'm proposing
here to structure (Sub)Committee communication. And
carpentries/conversations would be a channel for discussions which are
not so clearly associated with a single Carpentry, the Steering
Committee, etc.
[1]: #140 (comment)
|
We had a minor communications breakdown in #114 after the subcommittee formed. There was an initial call for volunteers and a public meeting in August, followed by internal committee work, followed by the new code of conduct and enforcement docs being published. However, between the formation of the committee and the publication of the results, there was no further public activity, either in the GitHub issues (#114, #115, #116) or in the steering committee minutes. This left non-members feeling cutoff from the internal subcommittee decision making process, and leaves the need for follow-up work to unify the subcommittee changes with the changes recommended via GitHub.
In earlier discussion around this in #15 and #20, and the consensus seems to be that subcommittees can do whatever they want in terms of publishing their activity, with non-members following along via the steering committee minutes for any actions that the steering committee takes based on subcommittee activity. It's hard to make a general rule to cover all cases (some discussion needs to be private), but the steering committee minutes aren't updated frequently enough for this to be a good channel for two-way communication.
Some subcommittee's do post minutes more frequently (e.g. here), which is useful for archival and reference. However, for subcommittees whose responsibilities cover more than one proposal (all of them?) it does not provide a particularly targeted channel for communicating on a single issue.
So it would be good to have:
Clear recommendations for non-members to publicly submit changes to the board. I've been assuming that issues and PRs in this repository are the appropriate channel for that, but it would be good to have formal documentation somewhere (along the lines of Subcommittees & TF guide #107, but for proposals in general instead of for new-subcommittee / task-force proposals). I'm happy to submit a PR for this if it would help.
A plan for keeping the initial submitters involved in further (sub)committee work.
One approach would be to keep the GitHub issue/PR active. For example, comments in the pull request like “the committee is about to consider this” and “the committee approved this” or “the committee suggests these changes” work well. For discussions that must remain secret, a comment in the issue/PR to that effect would be good. But squaring a requirement like this with the consensus from copy paste typo #15 and Public vs. private (sub)committee meetings #20 is difficult.
Another approach would be to publish proposed steering committee motions as PRs to this repo in advance of the vote. That way even a subcommittee which preferred to work in silence would surface their recommendations publicly before the steering committee acted on them. It puts (sub)committee proposals in the same boat as public non-member proposals. I'm happy to submit a PR for this if it would help.
Another approach would be to ask folks who were interested in ongoing discussion to join the subcommittee. This is the approach taken in specifying a procedure for handling discuss list CoC (or other list-specific rule) violations #114, and while there was a bit of a disconnect there, if the official recommendation was “join the subcommittee if you want to stay involved” there would be less change of confusion going forward. And reminding people of this before taking an issue/PR behind closed doors would help even more. I can submit a PR for this if it would help, but it's not my preferred approach, so if this approach is popular it might be better if a proponent picks up the PR.
The text was updated successfully, but these errors were encountered: