20180926 - Technical Council Meeting notes

10 min

Update

team

Quick review of backlog and status/updates:

• AES document will soon be locked down and submitted to TC for review

20 min

Definition of Done

Document

@Mike Gorrell

Summarize team comments and discussion next steps

• reiterating that this concerns new code; of course we should clean up tech debt but this is not an immediate requirement to do so

• we need additional details/checklists in some areas, e.g. list of supported browsers, what does GDPR compliance mean, what does UX approval mean?

• @Mike Gorrell to circle back with @Peter Murray and @Mark Veksler about how to make this operational

  • it should be more than a guideline, something we can/should enforce, e.g. via pull-request hooks, but how to do that is uncertain

 20 min

Pull Requests/Repo Management 

@Mike Gorrell and @Jakub Skoczen 

Discuss the role that the Core Team has in supporting new developers, and how Repos are managed. Discuss proposal by @Khalilah Gambrell and @John Malconian. 

KG: We are still experiencing delays with receiving tech design and PR approvals. These delays cause blockers that result in stories being pushed to 1-2 sprints. As a result, the Folijet team and I want to propose the following effective today. We hope this revised approach will ensure a smooth process for the additional epam dev teams joining the FOLIO community.

Tech Design review and approval 

1 – Team member/PO will send technical design to reviewers 

2- Team member/PO will schedule a meeting within the next 3-4 days to review design and get approval

PR approval 

1- Developer will add applicable Core developer(s) to review/approve PR  

2- Developer will send a reminder to that Core developer(s) to review/approve PR within the next 24 hours

3- If no feedback by Core developer(s) within 48 hours then the developer will proceed with PR merge

Any concerns with this approach?

And...

JM: I think we might want to implement Github CODEOWNERS for each repository so that developers know who are the best options for approving PRs for each repo. https://help.github.com/articles/about-codeowners/

help.github.com
About CODEOWNERS - User Documentation
You can use a *CODEOWNERS* file to define individuals or teams that are responsible for code in a repository. …

Also, it may make sense to assign an EPAM dev as a co-owner to many of the modules.

I should also point out that PR approvals are not required for most repos if you have write/commit access to a repository. So we can also make sure that they have the write permissions to the repo. But I’m not sure what process or policies have been decided on regarding what kind of access various devs should have.

Discussion

• There are tools like GitHub's CODEOWNERS file, but there is a concern that assigning core developers across many repositories does not scale

• Things committed against core modules need a higher level of scrutiny, but for modules developed by third parties, there is no expectation of approval from core

new business

Agenda for the next meeting:

• @Nassib Nassar will discuss reporting

Many people are out next week; next meeting planned for October 10, 2018.