danicat · December 10, 2025 11:33
diff --git a/ticket_template.txt b/ticket_template.txt
 The first section should be the "context", which shall be composed minimally of: 1) a brief description of what we have today, and; 2) a brief description of what we want to achieve. 

 Include references to complementary material when necessary, e.g.: link to github repo, docs, etc, but please make sure the ticket description is complete, meaning one can have a reasonable estimate of the effort by the content of the ticket alone.

 TO DO
 =====

 This is the list of things we want to do, written in a concise way (bullet points). Every item in this list must be actionable and have an acceptance criteria that covers it. e.g.:

 - update foo to add bar as required field
 - backfill schema xyz with bar = baz

 NOT TO DO
 =========

 List of things we don't want to do as part of this story. We should use this to limit the work in each ticket to be small enough to be handled in a timely manner. Not doing now doesn't mean never: complex solutions should be composed of two or more tickets. Reference future tickets when applicable. e.g.:

 - don't backfill the data for other schemas (TBD on xxxx)
 - don't create the airflow operator (TBD on yyyy)

 Acceptance Criteria
 ===================

 List of the things the person doing the acceptance test must see. e.g.:
 - querying foo on xyz should show bar field
 - records without bar should trigger an error
	The first section should be the "context", which shall be composed minimally of: 1) a brief description of what we have today, and; 2) a brief description of what we want to achieve.

	Include references to complementary material when necessary, e.g.: link to github repo, docs, etc, but please make sure the ticket description is complete, meaning one can have a reasonable estimate of the effort by the content of the ticket alone.

	TO DO
	=====

	This is the list of things we want to do, written in a concise way (bullet points). Every item in this list must be actionable and have an acceptance criteria that covers it. e.g.:

	- update foo to add bar as required field
	- backfill schema xyz with bar = baz

	NOT TO DO
	=========

	List of things we don't want to do as part of this story. We should use this to limit the work in each ticket to be small enough to be handled in a timely manner. Not doing now doesn't mean never: complex solutions should be composed of two or more tickets. Reference future tickets when applicable. e.g.:

	- don't backfill the data for other schemas (TBD on xxxx)
	- don't create the airflow operator (TBD on yyyy)

	Acceptance Criteria
	===================

	List of the things the person doing the acceptance test must see. e.g.:
	- querying foo on xyz should show bar field
	- records without bar should trigger an error
No results found