Code Health Group/20180117

Topics:

• Service/Extension/Component pre-first time deployment requirements
  • Discuss thoughts on having things like a Steward, Code Health, etc... as requirements.

Context of this discussion was one of the recent post mortem meetings re ORES where we discussed where the responsibility for graceful degradation fell - Platform or extension. If with the extension, then how do we ensure that this responsibility/requirement is met? This led me to want to investigate/learn about how we vet new services, extensions, components before we go into production. At a high level it doesn't appear that the services review process align much with the review queue used for other areas of code. The questions is whether or not placing more requirements on the components/service/extensions prior to first deployment makes sense. For example, an assigned steward, a certain code health, etc...

There was some concern about burdening one person with too many responsibilities (stewardship), that in many cases these components/services/extensions are too big for a single steward. We should look to the chain of responsibility when things don't go as planned/desired (i.e., reviewers when things are missed in reviews, developers when a testing gap is found, etc...). We should perhaps look to define those responsibilities instead over thinking the problem.

Another vector to think about is how we logically break things down, especially when something like a service is large and not easily managed by one person. We should probably avoid breaking things down based on organizational structure as that seems to change regularly enough.

Making sure that we align our approach with our values as an organization and community is also important. Emphasis on being a learning organization instead of a punitive organization. This is inline with the carrot vs sticks concern that was brought already. Are things like SLAs punitive in nature.

A couple of goals that are important are enabling ourselves to adequately support the community through proper resource planning and doing what we can to support community engagement. I (JR) believe that the two are tied.

Erika ask what some next steps might be and how she could help. Right now we are trying to get stewardship properly defined and implemented. Reviewing the materials we sent to Victoria and Toby for our discussion and providing feedback would be beneficial. [1]

Kunal's post meeting thoughts

The extension review process ("review queue") really only has a security review these days (for the code). Lately bawolff and Reedy have also been doing general code reviews as part of that process, which is great. We used to have a "performance review" and "architecture review" but both of those steps were removed, because they were ill-defined and mostly because they became a bottleneck, since only a few arbitrary people could do them. I think re-instituting some kind of well defined architecture review would be a good idea, but it needs to be decently defined what is being looked for, and who can do them (I believe previously it was just "Tim and Aaron").

• Stewardship info/flip board at Developer Conference
  • As we've not had a chance to talk to Victoria and Toby, may not want to let the cat out of the bag yet.
  • Discussed during meeting and decided to table this for now. Once we are ready to do it, we'll want to have something written up for pre-session announcements to point folks over to it.

[1] https://drive.google.com/open?id=1zjB6wSRXEdyqdlHWnAP7Z4BNng1u0BELs98-f8VTQTY