BuildCanada / BuildCanada/BillsTracker
Editorial Approach
- Dominant language
- TypeScript
- Stars
- 9
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
In Discord we've discussed BillsTracker either returning `yes` (We would vote for this), `no` (We would not vote for this), or `neutral` (We abstain on voting for this). The `neutral` are desired for things like some social issues that Build Canada does not want to take a stance on.
There are a handful of approaches to this. Would love your feedback @mikaalnaik @melkuo (who else should I be tagging here 😊)
### Overview
The app is currently designed to auto-review a bill once a user first clicks on the bill title.
### 1. Purely Editorial
For the bills we do not want to take a stance on, we hard-code the bill names into the codebase. This would allow us to display the Bill in such a way to make it clear that we are not going to take a position on this. If a user clicks the link to it it will not kick off a review. Or maybe there would just be no reason to make the title a link.
#### Upsides
We're certain that the bills we list for this will not be reviewed
#### Downsides
It takes work to keep this list up to date
### 2. Update the current analysis prompt
We update the analysis prompt to include a section for whether it will continue with the analysis or not depending on our criteria. The return value becomes `yes`, `no`, or `neutral`.
#### Upsides
Once deployed, no editorial work for the team
#### Downsides
This adds complexity to the analysis system prompt. Very low possibility of false positives or false negatives.
### 3. New two-step prompt flow
The first step in the analysis is a prompt that checks if it matches the Build Canada editorial desires. If the bill passes this phase, we continue to current analysis prompt. If it does not pass, we return `neutral` and save the bill as such to the db and display as desired in the UI.
#### Upsides
Separation of concerns. Simpler to optimize this prompt to almost never return a false positive or false negative. Keeps editorial logic out of analysis prompt.
#### Downsides
Some new complexity in app logic to build in a two step process (minimal). Very very low chance of false positives or false negatives.
### Manual Editorial
We'll probably want an admin feature to manually flag a bill as `want analysis`, or `do not want analysis`. If we went for the third strategy of two prompts, the app logic could check if this flag has been set and then skip the first prompt. This would also let us revert analysis of a false negative for a bill that gets reviewed but we didn't want it to be reviewed.
Contributor guide
No contributing guide indexed for this repository
Research direction
The issue names no files, tests, or entry points. First resolve which editorial approach to use, then trace the analysis flow, bill persistence, and UI behavior described here. Done means the selected workflow is implemented for yes, no, and neutral outcomes, including whether review starts and how manual editorial flags behave.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- full-stack
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100