| Existing Module Evaluations | ALL | Still in flux and can change going forward. Guiding Principles: No questions asked. Queue and Cadence: Queue: Most people said “yes” to keeping this queue in some previous conversations/meetings. What is the parent task? We are creating two Jiras, there is an always open parent and a sub-task is the evaluation. New evaulations at another cycle will be another sub-task of the parent task that represents the component. Are sub-tasks taken off of old closed tasks? The new module evaluations process is not changed and does not currently have this parent/child task. Nothing else happens with the original module evaluation. This new module evaluation task is not to be used as the parent task. The parent task here is only for existing module evaluations.
Process Summary: For the Review the findings bullet point, some level of communication will go to the team. There will be additional documentation that will go into further details on how this will or might work. Is the Evaluator the correct person to raise issues or perhaps the Product Owner? There is a lot of technical requirements to raise issues and the Evaluator might not be in the best position to do this. This can be discussed further in the other (additional) documentation referenced above. The Evaluator should be seen as a customer reporting a bug and they do not need to describe how to solve it or anything like that. An Evaluator should just report the findings and that is it. Is there a pathway to handle disagreements between Evaluator and the Product Owners or Developers?
Criteria, Tracking, and Follow-up: The parent task is primarily for tracking and history. When there are road blocks, go forward with what information we have. If that is not enough, then the module needs improvements. The team is doing their mediation on their own time. What does “link/linked” mean here. The linking here is being referenced via Jira ticket links. We create the Jira ticket and then make the links. What happens when outreach goes unanswered? It is important that we at least get some sort of acknowledgment. The review is done and the team should be expected to at least acknowledge the review. Referencing that the “outreach going unanswered” might be the wrong language here. If there is no answer at all, then excalation is needed. But there should generally be expected an answer but that does not mean the team is expected to solve or do anything in the context of “being unanswered”. Try to avoid conflating “being unanswered” with “not making changings”. These are two separate things and the document should better clarify this.
We want the teams to engage with us but we do not want to make the teams feel as if this is being imposed upon them. They should be able to handle these things at their own pace. We should include “reviewed”, “discovered”, and “addressed” (document has been updated to include this).
Existing Module Evaluation Check List If our goal is to take as little time as possible, then this document is written as intended. We previously discussed creating a “run book” for members to contribute to existing module evaluation. Would this document serve as a check list for an evaluator that is not on the council but can serve under the council to perform these tasks? Yes.
Existing Module TC Leadership Check List This guidance document is great, especially for the chairs. Recommend linking this page to the TC recurring calendar due to the ongoing and per-cycle duties. “Verify each … that has accepted”, there is implication there that there could be things that were not found but we are not creating issues for because it has not been accepted. The evaluators find issues and brings it to the team. If the Evaluator brings it up, but the team says no, then that can spur some discussion. What “Verify each … that has accepted” is about is putting the issue on the board and is not about whether or not the team says yes or no. This is agreement is about acknowledging that the issue is real. The acceptance does come before creating the Jira. The issue should not be created until the team has accepted it as an actual issue. The reporting cannot be done just because of the Jiras in this case because the Jira tickets do not include rejected/unaccepted issues.
Should there be a sub-group for maintaining the queue instead of the co-chairs? This sub-group would own this document and perform these steps. This sub-group idea is not being opposed, but it might just be assigned to a TC member. A single person should lead/manage this, but they could lead the sub-group, if such a thing is created. Sub-groups add potential meetings and most of this could be handled via regular TC meetings with some maintenance outside of the meeting. Just make sure creating a sub-group does not introduce more work. A sub-group general has an explicit/definite end-date and this proposed sub-group would not have an end date. The TC is entirely involved so the sub-group would not need to meet.
|
NA | Zoom Chat | | Jenn Colt 10:02 AM
https://folio-org.atlassian.net/wiki/spaces/TC/pages/1872166913/DRAFT+-+Existing+Module+Technical+Evaluations Maccabee Levine 10:33 AM
We have existing language on what conflict of interest means; I'll find it so we can link Olamide Kolawole 10:33 AM
https://folio-org.atlassian.net/wiki/x/AgCWbw Maccabee Levine 10:33 AM
We have existing language on what conflict of interest means; I'll find it so we can link Maccabee Levine 10:35 AM "The review team will be formed in a way to allow for a fair review and avoid either perceived or actual conflicts of interest. No members should have participated in the module's development, and at least one member should be independent of the submitter's organization. The lead evaluator will be assigned in JIRA; if the submitting team has concerns about the chosen evaluator they should contact the TC chairs within one week of the assignment." https://github.com/folio-org/tech-council/blob/master/NEW_MODULE_TECH_EVAL.MD#evaluation
Tod Olson 10:43 AM
I need to drop off, thank you everyone Maccabee Levine 10:57 AM
Thanks Olamide for the great work on this! |