Open kouloumos opened 2 months ago
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 |
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?
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.
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.
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.
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.
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.
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.
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:
needs: transcript
metadata flag. Includes all the sources with the metadata flagtranscription_coverage: full
, which is for recurring sources (example:chaincode-labs/chaincode-podcast
)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
evaluator
oradmin
role.NEXT_PUBLIC_APP_TRANSCRIPTION_BASE_URL
.env
variable to your local running instance of tstbtc (fastapi branch) or the staging deployment athttps://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 ( :x: ) 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 https://github.com/bitcointranscripts/bitcointranscripts/pull/492.
https://github.com/user-attachments/assets/5884c3a9-53a2-4cd3-a1b4-ef7a66bc6814