Table of Contents

Date

21 Mar 2017

Attendees

Actions items from previous meetings

• Former user (Deleted): come back to Former user (Deleted) with feedback on third point of proposed revisions to Desktop Wrapper WG charter
• Former user (Deleted): work with Maurizio Pillitu on a gap analysis of what would be required to CII certify / badge the  
  
  • Present that gap analysis at a future ESCo meeting
• Gabriele Columbro: write up some points on trust in transparent communities, with a particular focus on why identity, archival / auditability, and addressability are important for the voting system
• Peter Monks: commence archiving of 
• Former user (Deleted): promote upcoming hackathon internally within IHS Markit

Agenda

Meeting notes

• Quorum reached (25 minutes in)
• Long Term Maintenance for the  symphony-java-sample-bots project :
  • Peter: the project team for the  project (Maurizio Pillitu and I) would like to propose ☠️ Long Term Maintenance ☠️ (LTM) status for the project, given it's a sample (so not suitable for Activation) and the poor optics of remaining in Incubating for an extended period.
  • Frank: the project is very active, and I expect to add to the examples going forward.  Our definition of maintenance is a project that is not being updated or refactored - it's a one-time example.  So I'm going to say that if you are writing code and a project is actively maintained (as is the case here), it should be active or incubating.
  • Lawrence: I agree.
  • Peter: currently incubating has a 6 month restriction and the active state is intended to indicate to consumers that the code is production-grade, which these samples aren't (nor will ever be).  Archived status doesn't seem right for useful sample code such as this either, leaving Long Term Maintenance.
  • Frank: perhaps the code should be updated to meet the activation criteria?  I would consider meeting the active criteria as the preferred outcome.  Sample code is regularly copied and pasted into other software that goes into production.
  • Lawrence: perhaps active state should be expanded to include stable example code.
  • Peter: in that case how would naive consumers be able to differentiate production ready code from samples (which should not be run in production)?
  • Frank: I'm thinking we need a new classification for sample code.
  • Lawrence: perhaps, if we think it's not obvious to people.  But if people looked at a collection of code snippets that are examples that don't implement any major functionality, then I would expect they would understand that they're samples.  But if that's not clear enough we could create a new category.
  • Frank: Nick?  Mike?  Your views on this?
  • Nick: I think this could go a lot of different ways.  I definitely agree with Frank's observation that sample code goes into production all the time.  I don't think I have a strong opinion about it in terms of how we're going to apply the rules, and what the balance is going to be between having these aspirational rules and the realities.  Sorry that was a total non-answer.  
  • Peter: it's clear that sample code is often copied, adapted and merged into other production code, but one of the intentions of active state is for the project to ship production-grade binaries that can be deployed to production environments as-is.
  • Mike: I could see a sample being deployed as a binary.
  • Peter: released sure, but I wouldn't want that binary to be deployed to a production pod.
  • Lawrence: when I look at the definition of Active, I don't see much mention of binaries.
  • Mike: what does that even mean?
  • Lawrence: it doesn't say that people have to build binaries from the code; it doesn't say those binaries are the normal way the software is used.
  • Frank: a lot of us have taken source and built our own binaries from that source - this is a standard way of deploying open source.  Are we overthinking this?
  • Lawrence: yes.  But if someone wants to make a minor tweak to these definitions then I'm ok with it.
  • Mike: this is much ado about nothing.
  • Frank: if it makes you happy, even though they're going to be updated.  I'm ok with that.
  • Lawrence: what is your recommended solution Peter?
  • Peter: I have an opinion, not a recommendation; it's ESCo's role to define these things on behalf of the membership.  With that said, my opinion is that we should crisp up the definitions, so that (as currently intended) Active clearly identifies production-grade code.  Therefore samples have to go somewhere else, and right now the best fit is Long Term Maintenance.  But LTM is quite a grey area right now and could do with clarification too.
  • Frank: let's just explicitly define sample code as being Long Term Maintenance.
  • Lawrence: someone should come up with a specific solution that we can review.  Long Term Maintenance explicitly mentions that it includes sample projects, but it also includes that the project should have been previously active.  Some adjustments should be made offline.
  • Nick: I'm having trouble understanding the terminology.  Can't sample code be active, if it's an actively managed project?
  • Peter: agreed - our choice of labels is poor, especially "Active".  In fact Incubating projects tends to be the most active from a code contribution perspective, since that's where the bulk of the development work occurs.  Active ("production grade") projects often have lower velocity as they have so many more things to consider (backwards compatibility, avoidance of regressions, etc.).  FWIW our lifecycle is broadly aligned with how the Apache Software Foundation does things - they clearly mark projects as "incubating", "top level" or "attic" (which correspond to our "Incubating", "Active", and "Archived" lifecycle states).  But the history of how we arrived at our labels is from before my time - perhaps the ESCo members whose tenure pre-dates mine might know?  
  • Frank: it's also true that active code often contains sample code.
  • John: completely common.
  • Frank: I've pulled code out of symphony-java-client to this sample project, for example, but now I'm wondering if that was a mistake - that it makes more sense to keep samples with their projects.
  • Nick: example code is a vital part of any software project, so I'd agree with that.
  • Lawrence: one of the challenges is how Long Term Maintenance is constructed under the definitions we have - we're precluded from making functional enhancements, for example - but it seems to me we should adjust the definitions so this project ends up in a clear category.  And it's a technical detail where this project gets put.
  • Nick: what's the motivation for these categories?  It's not clear to me.
  • Lawrence: my understanding is to indicate to potential consumers what kind of quality or state of development the code is in.
  • Nick: isn't that usually inherently part of the artifacts within the repo - the readme, etc.?
  • Lawrence: there's certainly lots of ways people could determine that.
  • Nick: so I don't know if having these artificial categories makes things more complicated with little value.
  • Peter: the reason we have these states, and the membership (represented by the ESCo) mandates them is that we don't want project authors self-proclaiming their own quality.  We want to have an independent third party assess quality, security, compliance, etc. and then grant the status based on common criteria.  Self-reported quality is basically useless for consumers of the Foundation's project portfolio, since it doesn't scale - author A has one set of quality criteria and uses them to proclaim production-readiness, while author B has a completely different set.
  • Frank: I'm now thinking an active project should have sample code.  Separating sample code from the project it depends on doesn't make sense.
  • Peter: so what about projects that are samples of capabilities that are not themselves open source?  For example the  and  projects.  How do we categorise those projects?
  • Frank: let's take this offline and I'll take the action to work on figuring this out with Peter.
• Vote to approve Unable to locate Jira server for this macro. It may be due to Application Link configuration. :
  • Peter: this project is intended to be a Javascript (specifically node.js) client for the Symphony REST APIs.  There's been quite a bit of interest in doing this from others too (Former user (Deleted), Former user (Deleted), and Sarah Haimat).
  • Mike: to clarify, this is the beginning of a JS API - right now the code only wraps authentication and a few of the endpoints
    
  • VOTE: to approve  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    
    • Former user (Deleted): +1
    • Former user (Deleted): +1
    • john.stecher@barclays.com: +1
    • Lawrence Miller (Deactivated): +1
    • Michael Harmon: +1
    • RESULT: The motion passed.
• Vote to approve  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  
  • Peter: this contribution is a command line interface to rapidly setup a Symphony Extensions API application, but I'm just reading off the JIRA without a lot of understanding of what that means - Mike do you have any additional colour on this?
  • Mike: I'm less familiar with this one and not exactly sure what it does - it seems to be a developer tool to facilitate development of extension API clients
  • Frank: recommend pushing this to an email vote, so that we have more time to review the material
• AOB:
  • Quick background on ESCo Bot for Former user (Deleted)
    • Frank: I've been developing an ESCo voting bot that uses Symphony to manage our ESCo voting processes.  It relies on cross-pod however, so we've been unable to include you in the work thus far.
    • John: I'm jealous of those who can use the platform!  
    • Frank: I'm going to be adding an email-to-IM hook to the bot, so that it'll send you the notification and when you reply it'll get injected into the chat
    • James: can I also suggest that when a new vote is created an email is sent out as well?  This would be to support people who travel but who don't have Symphony mobile installed.
    • Frank: I didn't want to send out email until we worked out the kinks, but that's definitely coming.  Reminders and results will be emailed too.
    • Peter: question: do ESCo advisors have visibility into the voting activity?
    • Frank: yes there are two lists - voting and non-voting participants - ESCo advisors and secretary are in the latter list.  I haven't set the advisors up yet, but will do so shortly.  Nick do you have cross pod?
    • Nick: yes - I have an account in the public pod

Action items

• Former user (Deleted): work with Peter Monks on a proposed refinement to the project lifecycle.
  
  • MVP: ensure that each project currently in the portfolio unambiguously fits into a single state
• Peter Monks: schedule email vote for  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
• Former user (Deleted): setup ESCo advisors with ESCo Bot, once the code has stabilised to an appropriate point
• Former user (Deleted): enhance ESCo Bot with email integration, specifically for official vote recording, and to support Former user (Deleted)