BuildCanada / BuildCanada/BillsTracker

Editorial Approach

Open
#5 5 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.