Transcription Management Page

[kouloumos]

Overview

This PR adds a Transcription Management page to handle the transcription process in a running tstbtc instance. tstbtc has been converted from a cli to a transcription server (see fastapi branch) and this page communicates with that in order to manage the transcription process.

Details

The page features two tables, one for the transcription backlog and another for the transcription queue. Items from the backlog can be added to the queue for transcription. After transcription starts, it provides visibility on the state of the current transcription job.

Terms:

• Transcription Backlog: Includes all the user-suggested sources that leave in the bitcointranscripts repo with the needs: transcript metadata flag. Includes all the sources with the metadata flag transcription_coverage: full, which is for recurring sources (example: chaincode-labs/chaincode-podcast)
• Transcription Queue: sources from the backlog that have been added in the queue in order to be transcribed as part of the next transcription job.

Note: There is currently no visibility on past transcription jobs. Upon completion of a transcription job, tstbtc creates and pushes a new branch with commits for each new AI-generated transcript.

Testing the changes

1. You need evaluator or admin role.
2. You need to set the NEXT_PUBLIC_APP_TRANSCRIPTION_BASE_URL .env variable to your local running instance of tstbtc (fastapi branch) or the staging deployment at https://brilliant-growth-staging.up.railway.app.

By doing that and running this branch you will be able to see the current transcription backlog and add/remove to the transcription queue.

I would advice against ( ❌ ) starting a transcription job (by pressing the "Start Transcription" button) as the transcription process has an outside dependency (deepgram) and takes time (and credits) to complete. Currently, the bitcointranscripts repo is used as the source of truth for the transcription backlog, which makes it difficult to test with arbitrary sources of your choice.

Below you can find a screen recording of my latest test that resulted to bitcointranscripts/bitcointranscripts#492.

screencast-from-2024-07-16-15-16-41-llkgfmgu_FNQfMPaY.mp4

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
transcription-review-frontend	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 6, 2024 0:14am

[Extheoisah]

This is a good feature addition. Nice thought!👍
I haven't reviewed the code but from watching the video, I noticed you implemented two tables. One is to show the transcripts backlogs, and the other is to show the transcripts in the transcription queue. I am of the opinion that we should merge these two tables. Why?

1. To avoid cluttering the UI
2. Both tables have similar elements except the transcription status which is only present in the "Transcripts Queue" table.
   We can add the status to the backlog table and carry over the functionalities of the "Transcription Queue" table to the backlog table.
3. Better UX experience. With your current setup, you have to perform two actions - one for both tables to transcribe a source. However, we can eliminate one action such that if we have one table, the admin/evaluator only needs to use the checkbox to queue a transcript and the button to start the transcription process for example.

[kouloumos]

One is to show the transcripts backlogs, and the other is to show the transcripts in the transcription queue. I am of the opinion that we should merge these two tables.

I understand your thinking, but as the backlog and the queue have a different source of truth it makes sense to me to have them in a separate tables. That simplifies the implementation and allows for more flexibility for potential future changes.

Regarding UX experience, I believe that the current setup is better as it offers direct visibility to the user regarding what is in the queue and what is not. Having them in the same table will makes things weird, as the Transcription Backlog table can be filtered. I don't really understand your 3rd point; even if they are in the same table you'll need to "Add to Queue" and then "Start Transcription", so same process as now.

At some point it might make sense to have a single table but for now I prefer to leave it as it is.

[Emmanuel-Develops]

Good feature to queue without going through the CLI.
Following the video explainer at 0:36 it seems an admin can remove a transcript from the queue even when the job has started. The Remove from queue action and checkboxes are present, although they leave not long after at 0:57.

[kouloumos]

The Remove from queue action and checkboxes are present, although they leave not long after at 0:57.

Good observation. As I mentioned, this recording is from my latest testing, so I removed the checkboxes as soon as I realized that the admin can remove from queue during the transcription job.

[Extheoisah]

but as the backlog and the queue have a different source of truth it makes sense to me to have them in a separate tables.

I don't understand the two different source of truth. Pls explain.

That simplifies the implementation and allows for more flexibility for potential future changes.

I'm not sure how having two table simplifies implementation. AFAIK, having one table doesn't complicate things in anyway since we're adding just the status column and the start transcription CTA to the backlog table.

[Extheoisah]

I believe that the current setup is better as it offers direct visibility to the user regarding what is in the queue and what is not. Having them in the same table will makes things weird, as the Transcription Backlog table can be filtered.

Well, given we have different views on this, I'd like other reviewers to give their thoughts on the UX cc @Emmanuel-Develops @0tuedon @IgboPharaoh

I don't really understand your 3rd point; even if they are in the same table you'll need to "Add to Queue" and then "Start Transcription", so same process as now.

Exactly! Only that you do it in one table action as opposed to two separate table actions.

In general, I'm open to having a one table implementation in the future not now. But I believe having two separate tables isn't the best way to go.

[kouloumos]

Well, given we have different views on this, I'd like other reviewers to give their thoughts on the UX

We discussed this privately with @Extheoisah and we are moving forward as it is.