Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Has everyone (anyone) had a chance to review this yet?
@Tod Olson summarized the comments / input from TC members to date. Some of the dates needed to be pushed ahead as "near-term", "long-term" etc mean something different now than they meant when the document was drafted.
In some instances, the commenters felt that certain objectives were really under the control of the service providers rather than the TC (dependencies on hosting environments and such). In such cases, @Mike Gorrell and @Ian Walls believe we might want to remove those objectives.
@Zak_Burke proposed that the TC could structure some of the minimal performance requirements, while also ensuring that performance is a priority of the developers and tech architects (preventing things like memory leaks etc)
@VBar asked whether the bullet in question (#6) was really a performance requirement.
@Jakub Skoczen sees this as belonging to the realm of SLA terms. The TC should not have a defining role on point 6.
@VBar indicated we should be able to provide performance metrics within the project.
@Marc Johnson believes that the TC needs to clarify and agree on concepts like performance / stability requirements first before moving forward with this document. Also, for today, we're just trying to figure out which Council should own #6 and whether it should be the TC.
@Ingolf Kuss offered to take this point to the SysOps SIG for discussion - to help define the requirements and report them back to the TC.
@Craig McNally recommended that we first note the topics in the document that we agree on, then focus in later meetings on the topics in the document that need additional discussion.
@Tod Olson noted that the PC and TC would have input on FOLIO "roadmaps," just need to specify which roadmaps - a technical one vs a "shared roadmap"?
5-10 min
Technical Decision Making Process
@Jeremy Huff
@Zak_Burke
This is a carry-over from previous weeks.
The tech leads group not being a decision making body
Whether it's realistic and/or desirable for the TC to make every technical decision
There was some overlap here with the external code submission topic
@Jeremy Huff suggested that we form a working group to define more detail around this topic. @Craig McNally agreed that was a good idea or alternatively, we need other proposals
@Zak_Burke volunteered to identify categories of decisions the TC makes and suggest applicable processes
5-10 min
Participation and Attendance Expectations
All
@Jeremy Huff created a page to track working groups... Should we take a look together and see if anything should be added/adjusted?
Is there anything else we want to do for this topic?
Is it enough to ask those in sub groups to add them to the page?
Action: we should discuss at next meeting about appointing sub-groups when there are not enough volunteers.
Discussion:
Zak: some hesitancy to volunteer when there is not a clear charter for a subgroup, i.e. how do we know when this is done?
Maybe we need to define these things early on, like a list of deliverables
Phil: not always clear what the time commitment will be, having an idea of the expected time commitment would be useful
Craig: Tricky to think about volunteering people, especially with the subgroup work tending to fall to the same people.
Jeremy: could use multiple ways to do this, maybe subgroups for some matters, and for some matters perhaps assign to an individual to make a proposal. Perhaps could charter a TC member to assemble a subgroup that may include non-PC?
Stuck for now: when we don't get volunteers, the need does not go away.
Summary to remove obstacles to volunteering:
When we need a Subgroup, need to know what the output is
Set some expected time bounds
tricky, as cannot always finish as expected once you get into the issue
Default would seem to be to extend the time limit
Could split the time commitment: meet so often, and for so long
Another meeting rules thing: should we have a formal policy/discussion about attendance, discussion, and decision making when attendance is low/less than half?
Action items
@Zak_Burke : reach out to developers of Translation app, invite to TC subgroup to discuss architecture issues.