Versions Compared

Old Version 3

changes.mady.by.user Sean Bohan

Saved on

compared with

New Version 4

changes.mady.by.user Sean Bohan

Saved on

Key

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

...

  • Sean Bohan (openIDL)
  • Nathan Southern (openIDL)
  • Yanko Zhelyazkov (Senofi, Co-Chair)
  • Peter Antley (AAIS)
  • Joseph Nibert (AAIS)
  • Faheem Zakaria (Hanover)
  • Jeff Braswell (openIDL)
  • Aashish shrestha (Chainyard)
  • Tsvetan Georgiev (Senofi)
  • Allen Thompson (Hanover)

Agenda Items:

  1. Antitrust Policy
  2. Status Updates
  3. IWG Near Term Agenda
    1. GitHub 
      1. Policies
      2. Prerequisite for the Merge
    2. Maintainer Policies
      1. Maintainer Role
        1. Technical Leadership at a code level
        2. Help onboard new contributors/maintainers
        3. Review/Comment/Approve PRs
        4. Escalate to AWG or TSC
      2. Maintainer Selection
        1. 2 Maintainers per Infrastructure Partner
        2. 1 Maintainer per Member (Carrier)
        3. 2 Maintainer openIDL Org
        4. 2 Maintainer AAIS
      3. Fabric Maintainer Policy as an example
    3. Merge (ND POC, Testnet, etc.)
      1. Inventory (outline changes/improvements, what can use, feature/bug fix)
      2. Model: Network vs. Application Communities
    4. Developer Certificate of Origin (all of openIDL and new contributions)
    5. License Compliance (LF has automated tools)
    6. Security
    7. Documentation
      1. Currently ReadTheDocs
    8. Bug Tracking/Issues
      1. GitHub Issues, Jira?
    9. CI/CD
    10. Release Management

Minutes:

Maintainers

  • Yanko
  • Dont have to come up with exact numbers
  • Currently have 3-4 orgs - openIDL, AAIS, Chainyard, Carriers
  • how do we assign particular role
  • in terms of approving changes to codebase, question - who should approve to get a PR in main codebase
  • carriers? 
  • do we need IPs responsible for techncial execution of change - well tested, standards, practices
  • approval rocess should be more complicated than techmically adept
  • understand business perspective on changes
  • would feature be used, significant, mainstream feature, plug and play
  • Ken
  • Quorum for commits - no red tape, no surprises either
  • in the beginning, make sure all have a chance to look at it before approved, contriversioal then escalate
  • Aashish 
  • initially take a look, when we have enough people to contribute, set up processeing votes
  • Insurance agencies as stakeholder? wouldn't rule it out, but don't tend to have big IT departments, shouldn't close that off
  • Yanko
  • how do we approve changes, not so much pull requests
  • need to set a good process in terms of reviewing issues and tickets
  • make sure that changes are approved before we reach
  • Jeff
  • distinction - changes and updates in master 
  • Commits to master branch
  • KS
  • trust a couple reviewers to make judgement


Action items:

  •   
  •   
  •   
  •