Hi tech council - I would like to request that the inclusive documentation guidelines from the Google developer documentation style guide be followed as part of writing documentation on the FOLIO wiki. (link: https://developers.google.com/style/inclusive-documentation?hl=en )This style guide is what is used for the FOLIO docs site, but the FOLIO wiki is a very public, visible representation of the project and its values, and it is referenced much more than the docs site right now. Adding a link to the inclusive guidelines to the onboarding links could be a place to start.But the request is basically that these guidelines be a standard and that when documentation falls outside of these guidelines, requests for correction will be accepted and implemented. The assumption is that mistakes will be made but that these guidelines give us a goal to aim for. Thanks for your consideration. Let me know what else might need to be done to move this forward or to discuss it more.
Goal: Make a formal decision on adopting the Google developer documentation style guide for all technical documentation in FOLIO, and clearly define the expectations.
Suggestion: The expectation is that not all technical docs will conform to the rules in this guide, but the project should make adjustments as things are discovered. The intent being that most technical documents will eventually be aligned with these guidelines.
Does the RFC proposal meet the purpose outlined here in this document?
Are there other proposals for a decision making process (maybe that borrow parts of the RFC process)?
Last time discussed: "need some feedback, will come back next week". Skipped last week due to low attendance.
Postponing, need more feedback on document.
20 min
(Depending on attendance)
Participation and Attendance Expectations
All
Low attendance/participation from some members is becoming concerning - it's probably worth aligning on expectations.
Use of proxies?
How to handle low attendance
Cancel the meeting?
Still meet and make progress on things that don't require decisions to be made, e.g. review proposals and provide feedback, at least go through the usual updates
...
Discussion:
Strong preferences for not cancelling meetings.
Comments in favor of leaning on proxies, but not too much.
Some projects (e.g. NPM) have minimal requirements for attendance, not clear we want to formalize this.
Need more participation outside of meeting, there is more to be done than 1 hour per week in meeting.
How to set expectations about participation?
Probably best to set vague expectations to promote useful participation.
Examples of participation might be useful
Setting metrics is probably neither practical nor has the right tone.
Baseline
Encouragement at all meetings is encouraged, and if cannot make a meeting send a proxy
Happy to use half-plus-one to make decisions, and lean on lazy consensus unless there is a call for a vote
Another meeting rules thing: should we have a formal policy/discussion about attendance, discussion, and decision making when attendance is low/less than half?