Versions Compared

Old Version 14

changes.mady.by.user Peter Monks

Saved on

compared with

New Version Current

changes.mady.by.user Peter Monks

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Actions items from previous meetings

...

  • Quorum is reached (4/5 ESCo leads)
  • Working Group health:
    • Aaron: I've been tasked with figuring out the measurement of WG health, and providing info to ESCo to support reporting to the board.  This has proven a little more complex / not easily quantifiable as projects, where there are lots of metrics around source code repositories and activity that don't translate to a WG.  The data Iv'e been providing thus far has been around attendance and # of votes (an average of zero) for WGs.  So I wanted to ask you to think about what sort of information you think would be useful to report to the board, to give them a picture of how WGs are faring.  At this stage the solution that I've been bandying about is that rather than attempting to collect numerical metrics, to instead provide a standard survey to WG members asking questions about the degree of collaboration, the degree to which they feel there are meaningful opportunities to contribute to the WG, whether the WG is having able to carry out its charter, etc.  This has the disadvantage of giving WG members more busywork, but was the only way I could think of to capture non-quantifiable indicators of how WGs are doing.  Any ideas on what else to collect?
    • Frank: the minutes we take on WGs - the ones that show the interaction within the group - I don't know how to quantify that, but I think they could be a good sign of activity e.g FOS early on, the API WG when working on the charter.  Lots of interaction between participants is something we could attempt to quantify.  It's really about communications within these WGs.  We could also look at the message boards and wiki to see if there's activity there.  The recent proposals in the FOS GW has started a lot of activity - that quantifies as something functional - a community that's discussing topics and items.
    • Aaron: that's helpful thanks.  I'll think about how we can quantify that activity.
    • Frank: a counter to that - the API WG has been fairly quiet recently.  There's been nothing on it, and we should do something about it.  But there's quite a difference in activity there.
    • Aaron: too much to ask to send a short 1 page bubble survey to WG members to get their view on how they think a WG is performing vis-a-vis their charter, perhaps once a quarter?
    • Frank: I'd send some SurveyMonkey surveys to the participants and make them reply.
    • Aaron: I'm not sure we can make them.  (wink)
    • Frank: that's been the challenge, and where getting people's cell phone #s is important.  (wink)   I think we should try to create some more movement in these groups though.
    • James: I think it will be difficult to get pople to fill in a long survey.  I'd keep it to 3 questions.  I think mining of the minutes would show attendance and the number of people talking.  Qualitatively, given that you guys show up to every meeting, you'd be as qualified as anyone to measure active conversation.  But only the members can assess whether things are progressing.  A short survey on "is the WG working towards its goals" might work.  But it has to be short.
    • Aaron: to the extent that we'd be gleaning meaning from the minutes, how would the ESCo like that presented, to support reporting to the board?
    • James: number of people actively engaged in the conversation, whether on the call or via email.  Literal count on number of people in conversations - 2 is materially different to 5 or 6, for example.  And if everyone is using the mailing lists it should be easy to count, and tells us something very quickly.  That's relatively observable going forward too.
    • Aaron: any further thoughts?  Ok I will take those suggestions into consideration and come back to ESCo with a draft survey and perhaps a sample report of what we'd provide and solicit your feedback on it.
  • Voting mechanisms
    • Frank: I've been spending time building this voting bot, and everyone seems to like the idea of having the bot not only handle notifications but also voting itself.  Then you (Peter) raised a valid point that voting can be certified by the public (e.g. via email or in-person in the minutes) to ensure that votes are issued by frank dot tarsillo at markit dot com into the Symphony Foundation, and that's the record of Frank Tarsillo's voting.  The bot itself doesn't do that - it's in a private chatroom that doesn't have public visibility.  The next suggestion was for the bot to send emails, but the bot is interpreting the vote via Symphony chat into that email, and even if I put "Frank@noreply.com" and sent that to the ML, there's no way to certify that it was really me - my vote could be fudged.  Absolutely a valid point, so how do we certify an identity of an ESCo member through an alternative medium, or, do we change the governance model?  I've thought about this over the weekend and I thought one approach is to use PGP or GPG (public/private key encryption) to sign the vote objects, and add that to the bot's email, so that the bot's relayed emails can be certified.  That's one idea - did everyone get what I described?
    • Laurence: what do you mean when you say email?
    • Frank: if the bot sends the vote email, it will come from "norreply@bot.com", and even if the text of the email says the vote came from Laurence, it didn't actually come from you.  And anyone could spoof that email.
    • Laurence: you mentioned this is a by-laws issue?
    • Peter: just to clarify - it's not a by-laws issue, but it does go against the previously ratified voting mechanics
    • Laurence: I like this as a technology demo.  There's also a strong natural compensating mechanism for fraud, given the small population of voters.  I like the idea of using cryptographic signing, not least as a technology demonstration.
    • Peter: there's a bigger issue here, which Gab may wish to weigh in on, and that is that we're also trying to be "compatible" with well-established procedures in use in other long-running open source communities and foundations (e.g. Apache Software Foundation).  There are benefits if the procedures we use are familiar, broadly adopted and understood well beyond the Symphony Software Foundation.
    • Gab: two comments: on the requirements side we're pretty aligned - whatever mechanism we decide on, on top of ensuring user friendliness, we have to ensure votes are transparent and linkable.  Voting via emails is easy in this regard.  I wonder if what we're discussing here is a bigger question we haven't answered yet - identify management within our community.  I don't necessarily want to scope creep, but in my experience with Apache, all important emails were PGP signed.  For example I could not do a release of my code without a GPG key, and my key also had to be cross signed by the community - this is the "web of trust" in Apache speak.  I don't want to stop progress on this one, as long as we have identity, archivability and linkability of votes and responses, I'd be ok with any solution.  But the question of how we manage identity for the community may resurface.
    • Laurence: there's a controlled list of users on Symphony - that and GPG are both stronger mechanisms than email.  Building that into the voting mechanism doesn't seem ridiculous.
    • Frank: we could also include message identifiers.
    • Gab: I don't wish to opine on one technical solution, but the requirements are important, including verifiable identity of the sender.
    • Laurence: my one thought would be that the Apache Foundation uses email and GPG, we're operating very heavily around a messaging & communications platform and I wouldn't expect our mechanism be the same as other communities, given the technology we're focusing on.
    • Gab: we're saying the same thing.  I'm not interested in promoting specific solutions.  I'm interesting in identity, archiving and addressability (linking) requirements.  Do you agree that those requirements are table stakes for a transparent community?
    • James: I have to drop as something's come up - can I record +1 for bot-JIRA archive vote?
    • Peter: sure - recorded!
    • Peter: just to repeat Gab's question: does ESCo agree that identity, archiving and addressability (linking) are minimally viable / required / must-have requirements for a voting procedure?
    • Laurence: frankly I'd rather ground it in specific questions.
    • Gab: would you like an example?  As long as we have a record we can refer to from other communication exchanges (which is why Symphony chat doesn't work - I can't link to it).
    • Frank: well we could have a web link to those specific messages.
    • Gab: again, I don't think I should be commenting on technical solutions.  My question is mostly related to requirements - do we agree on those 3 requirements (which in my experience, are fundamental to running a transparent community)?
    • Laurence: since you're asking, the view I have is that we should look at specific procedures and see if it makes sense.  I don't necessarily disagree with the objectives but I wouldn't sign off that those are minimally viable.  They're too theoretical.
    • Peter: without agreeing on requirements, you can't verify that any particular procedure has successfully achieved them.
    • Frank: I also don't want to vote on something now.  I'd like Gab and Peter to write this down, as it's not clear in the governance description.  If you can write down why those 3 are critical points, then I can come up with a solution and present it to ESCo.
    • Gab: these aren't in the by-laws, to be clear.  These are best practices for open, transparent communities and we want to apply them in this context to build trust and collaboration.  But happy to take an action to elaborate on this.
    • Laurence: I second Frank's point.
    • Peter: Frank would you like to describe more of what you've done to date?
    • Frank: sure - significant progress this morning.  Two classes of user in the bot - wider non-voting ESCo users, and voting users.  Anything that's sent to the bot will be relayed to the entire ESCo group.  I didn't add everyone yet, because of difficulties with the APIs, but you can at any point put in a new vote.  Once a vote goes in:
      • It has an identifier
      • The vote is in an active status
      • The 72hr deadline is built in
      • Reminders occur every 8 hrs (these durations can be changed if we wish)
      • Only active votes can be voted on.
    • Frank: The system will take in vote responses by simple command line e.g. /vote <id> yay / nay / abstain.  If you do /list <id> it will show who has voted, in a table.  As people respond, the status and measurement of the vote will be updated.  The vote will stay in active state until the necessary number of responses are received or the deadline passes.  At that point the vote will go into archive state, with the result of the vote (either passed or failed).
    • Peter: do nay and abstain votes require explanations?
    • Frank: not yet, but I can put that in
    • Laurence: minor feature thought would be to allow shortcuts - y, n, a
    • Frank: yeah we can modify things as we go.  In terms of status, I'm working on it - you're my testers.  I will let you know once I've distributed it into our PaaS, which is where it becomes truly active and can be battle tested.  That should be another day or so.
    • Laurence: in the meantime we can use a procedural workaround: we could run these votes via the bot then ratify them in ESCo meetings.
    • Peter: another question - what are the plans for open sourcing the bot?
    • Frank: the code is pretty ugly right now, but I'm going to clean it up at the end.  I'm also tying it into the AI work I'm putting into the symphony-java-client.  I don't think open sourcing is an issue - I'd love to open source the voting bot and continue enhancing it.  I would love to put an API on it, for example.  Obviously I'm keeping the supported voting methods simple right now - ignoring electoral voting models etc., but I'd like those approaches to be supported too, and that can also be done in the open by other contributors.
    • Peter: seems like it's two bots: a general purpose multi-party x-pod bot and a voting bot - any thoughts of architecting it that way?
    • Frank: yeah we already have that - the proxy bot in the helpdesk-bot project does multi-party x-pod.  This new bot doesn't actually use the proxy bot, but that's another thing that could be added.
  • Vote: Archive of :
  • Hackathon promotion:
    • Peter: we have a hackathon coming up on April 6th at DB Labs in PA.  We're already working to promote this internally within the LLC, so this is mostly a request for Frank.  If you have any local developers available on that day, we'd love to have them come join us.
    • Frank: we don't have much developer presence in Silicon Valley, but folks do visit there from time to time.  Happy to promote internally.
    • Peter: thanks - appreciate it!
  • AOB

Action items