Create Translator Release Guidelines

[tursynay]

@NCATSTranslator/tact-voting-members , please review the release guidelines. At the previous TACT call it was decided that TACT team would review the guidelines, discuss here and then vote to adopt these guidelines officially. Please provide your input by the end of Tuesday November 14.

[cbizon]

IIRC we don't want people to vote yet, we want to have a general discussion of the guidelines before a vote so that we can make updates before people approve/disapprove. Is that right @tursynay ?

[cbizon]

If it is correct, probably best to make this a draft for the moment...

[karafecho]

@cbizon : I'm a bit confused. I was under the impression that we already had sufficient discussion and that we were ready to move to vote. I'm fine with additional discussion, but I'm not sure it's necessary, given that we will be revisiting the initial release cycle timeline and guidelines during January's retrospective.

The meeting minutes state the following, so it's a bit unclear:

11/02/2023
Attendees: Chris B,
Agenda:
Review and approve Release Guidelines
Hotfixes
ACTION ITEM: Create a PR for the Guidelines sections. TACT team to review and discuss in PR. We will have the voting member approve these guidelines after a few days of discussion.
For UI - requesting to be allowed to make some changes to the UI outside of the cycle frame.
Gus will take it back to the UI team for discussion.
TACT GitHub: https://github.com/NCATSTranslator/TACT

[karafecho]

Note to all: If approved, the Translator Release Guidelines will be archived with the other Translator Guidelines as a G-doc. Here is a link to the current draft of the guidelines in human-readable format.

Apologies for the confusion!

[karafecho]

@tursynay : For review purposes, perhaps we can created an md file, as @andrewsu suggests in #4 and include a link to the G-doc that will be archived with the other Translator Guidelines, assuming that the Translator Release Guidelines are approved?

[saramsey]

I added a comment to the Google doc. Thank you @karafecho

[edeutsch]

It seems to me that we have 3 different DRAFT PRs here #2 #3 #4 and I don't grasp how they are different. They seem to be more or less the same thing in different formats maybe?

I'm thinking this just should be a single clear PR?

[edeutsch]

I was advised that my other comment was placed on the wrong PR. I'm a bit confused by the 3 PRs, which seem very similar. But here are my comments repeated on this PR, which may be the right one:

Well, I'll go on record to say that I think this sort of process is premature. My impression is that there are lots of things that need fixing and improvements that are now not getting fixed or improved because we're frozen until a long ways off. Eventually when we have a product that doesn't have lots of problems and most of the development is doing new things, this would be a good process. But for now, I think this process just slows down our progress. But it seems like it was already decided that this is what we're doing, and we're already doing it. So I vote "it is too soon to do this".

[cbizon]

Thanks for the comment @edeutsch . To follow up a little bit and clarify - I think what you are saying is that this process makes the time from finding a problem until a fix is in production too long. Or are you saying that this process reduces the number of fixes that will be in place after a coordinated release compared to what would be in prod after the same amount of time with a continuous release?

[edeutsch]

Thanks for the comment @edeutsch . To follow up a little bit and clarify - I think what you are saying is that this process makes the time from finding a problem until a fix is in production too long. Or are you saying that this process reduces the number of fixes that will be in place after a coordinated release compared to what would be in prod after the same amount of time with a continuous release?

I think both.

I think what you are saying is that this process makes the time from finding a problem until a fix is in production too long

Definitely this. Fixes/improvements that we've already made won't see production until January I think, which seems like a long time away. By January I will have completely forgotten about fixes I made in October, and if there is a problem deploying them to PROD for whatever unanticipated reason, I will need to remember back to October what we were even doing.

Or are you saying that this process reduces the number of fixes that will be in place after a coordinated release compared to what would be in prod after the same amount of time with a continuous release?

I feel also this, although I really have no data to back this up. I suspect there will be a sense of "I've already fixed 10 things in CI. But testing still shows lots of broken things in TEST and PROD because my changes haven't made it there yet. So we'll just wait for eventual deployment to see how things look when all this is deployed, and then continue to do more fixing after that happens." I suspect the proposed process substantially reduces a sense of urgency to make improvements, and increases the cognitive load of trying to remember what has been fixed in which environments ("is this a new bug or is this a bug that I fixed a month ago but just hasn't been deployed yet?") and the easiest relief for that is just to wait a couple months until everything is synchronized again before doing more, and get back to the grant proposal I should be writing.

In any case, I'm not really trying to throw sand in the gears on this proposal or die on this hill. I'm just trying to take Will's comments to heart that there are people who don't bother to speak up when they think we're not going in the right direction because it's too much trouble/won't change things anyway, and actually speak up. (I haven't actually spoken to Will about this topic, so whoever he's referring to is not me. But I do feel that way sometimes). I'm speaking up, but I'm totally fine to be outvoted by those who feel this is the right thing to do.

[karafecho]

Note to all:

If approved, the Translator Release Guidelines doc will be archived with the other Translator Guidelines as a G-doc. Here is a link to the current draft of the guidelines in human-readable non-md format.

The Translator Release Process Details doc contains detailed steps regarding the release process that are not appropriate for the high-level guidelines doc, but rather are intended to inform Translator team members on how things are expected to work in practice. Sort of like an SOP.

Apologies for the confusion!

[tursynay]

During the winter 2024 release schedule retrospectives relay session, this process will be updated and finalized. Will merge this PR then.