[Members] Resurrecting the comms team
Guus der Kinderen
guus.der.kinderen at gmail.com
Wed Feb 21 13:29:51 UTC 2018
Since the summit, there appears to be a drive to "get things done", which I
believe we should wholeheartedly support. If forming a workteam helps, I'd
certainly be in favor. Defining access permissions based on
team-affiliation seems like a good way to structure those permissions to
me: it's a clear definition, which prevents us from having to jump through
the same hoops every time we want to apply an access change - which I've
experienced can be cumbersome.
On 21 February 2018 at 13:39, Kevin Smith <kevin.smith at isode.com> wrote:
> On 21 Feb 2018, at 12:15, jc at opkode.com wrote:
> > Am 21. Februar 2018 12:02:49 MEZ schrieb Kevin Smith <
> kevin.smith at isode.com>:
> >> On 16 Feb 2018, at 11:11, JC Brand <jc at opkode.com> wrote:
> >>> Based on the summit discussions we had around promoting XMPP and the
> >> informal
> >>> comms team that was assembled there, I'd like to propose resurrecting
> >> the
> >>> official comms team.
> >> As I mentioned at the Summit, I’m not convinced that going through
> >> setting up the comms team formally again is a good idea.
> > One reason why an official team seems necessary to me is so that we can
> give team members access to the xmpp.orggithub repo so that they can add
> newsletter entries (and potentially add other material such as blog posts).
> Just to be devil’s advocate here, but people can do all those things
> without needing write access to the repo. As always, with my iteam hat on I
> remain cautious about handing out write access to things particularly
For my taste, that's over-cautious, which prevents us from being productive.
Within our small group of members, and more so within a smaller group of
workteam members, we must be able to trust on the good intentions of
individuals, and for them to be able to apply changes, or take
responsibility for fixing problems that they introduced. We're not talking
about handing out root access to servers here: all changes to a repository
are publicly recorded, and can be reverted. When deployed, things run in
containers, limiting the scope of damage, if it does occur.
I am much in favor for a permissive model here: give people the tools
needed to be effective in managing our public outlets, and only revoke
access if things have proven to go wrong - which I very much doubt will
> I think that until the team’s active and producing stuff informally, going
> through the effort of having an official work team etc. seems premature
> (we’ve been here before). Others may disagree.
> >>> At the summit we came up with the idea of sending out a regular
> >> newsletter,
> >>> which would be a curated list of articles, tutorials and news
> >> relating to XMPP.
> >> These are good ideas.
> >>>> The team's mission is to inform the XMPP community and interested
> >>>> parties on news and recent developments within XMPP ecosystem.
> >>>> The team consists of XSF members who have indicated their desire
> >> and
> >>>> willingness to join the team and execute its mission.
> >> I think that an open team like this sounds good in theory, but would be
> >> counter-productive. We usually have explicit membership, generally
> >> approved by Board or Council, and if we *do* restart the comms team, I
> >> think that’d be appropriate here too.
> > So we add "and has been approved by the board/council.”
I suggest we have an explicit list of members, that are board-approved.
> Board, probably, yeah.
> >> (Incidentally, a chair is also needed)
> > We can elect a chair.
> I think, from memory, that the charter needs to say how the team’s leader
> is selected, although I could be wrong. I’d suggest just ‘chosen by Board’
> or somesuch.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Members