| 30 min? | Jono's thoughts and comments on Code Review and Incident Management in an Open Source Project | TC | - Jono Bacon to join.
- 4 main points:
- Code
- Open review
- Issue Management
- Roadmapping
- What's unique about this project? Different structures, etc?
- Not seeing much activity in open/drive-by pull requests
- Didn't see much discussion around PRs and implementation decisions
- seem to be happening on GitHub, in Slack
- Is this a reflection of state of FOLIO, only one site in production?
- Has not seen much evidence of open code review
- On UI side, have moving in this direction, code submitted as PRs and waiting for peer review before merge.
- Also many distributed teams, review internally.
- One challenge is the size of the project and how to process PRs, e.g. core team has to do a context switch for any PR for core.
- We think there is a slow steady trend to bring these up
- Underlying thread: one area where JB has seen OSS run into trouble, when paid employees seem to have a different workflow than the rest of the community.
- Moving discussions to a platform like Discourse, where you can find previous discussions.
- Right now, Slack useful for real-time feedback during bug fixing. May change when we're more in production.
- There is a need both for synchronous discussion like Slack but also for async, bookmarkable discussion.
- JB sees benefit to structured communication, as in a PR. One thing that has worked elsewhere is to establish a cultural norm where a productive sync conversation is copied to the PR.
- Ideally there would be one source of truth, conversations currently split between JIRA and GitHub.
- Very common for people to say that GitHub Issues are insufficient, JIRA is great for breaking issues down in to pieces and relationships between.
- JB had seen some small traffic in GitHub Issues, had been unaware of the JIRA instance.
- Would recommend the JIRA instance be made more visible. Though is in Developers pulldown from main nav. bar.
- Drive-by PRs: how do projects manage those?
- Problem: devs are incentivized to fix code in their areas of interest, not incentivized to triage or do code reviews. One way to kill interest is to let PRs and bugs go unnoticed, unreviewed.
- Additional: the audience for this project is not developers, bugs come in from non-devs, are triaged by POs.
- How to provide a simple set of tools for librarians to submit issues? Ran into this problem with Ubuntu, got bug reports from techies, but majority non-tech users.
- Sees a role for an integrated user community, with a place to ask for advice and report trouble, something like Discourse could play a role.
- We have some of this, new sites kicking the tires will often find the Discuss board.
- Some of this also happening in the SIG meetings, Slack.
- Questions:
- PRs, some projects devs submit PRs with bug reports
- Testing
- General approach is build out set of unit tests.
- Ideal is to have a policy that says any new classes, methods will have unit tests attached. Test suite run before PR accepted (This is in place now)
- How to go back to legacy code and get coverage in place (We have tickets in place to do this, and QA monitoring of coverage)
- Manual smoke testing, also go out to technically-savvy librarians who can test. (we also do a version of this)
- Release management, process for what features are included in a release, how is this done in other projects?
- JB fan of regular cadence-based cycle, x-many months. Gather requirements from community and determine what features to target. (This seems similar to our capacity planning and issue review process)
- Main point is to solicit feedback from community. Our process is continuous. Is the suggestion to turn this into an event? JB thinks an event quarterly (as opposed to semiannual) would be difficult. If continuous feedback works, then we're probably good.
- One point is that having a cadence is important, there's a problem with just having a release whenever.
- Visibility is one thread that runs through all of this
- We're doing many of the recommended things, but often not so visible. Maybe the effort needed is to make these more visible.
- Capacity Planning Team does much of this.
- Once current challenge is balance time between new features, support, bug fixes.
|