List view
- No due date•1/1 issues closed
- No due date•7/7 issues closed
- No due date
- No due date•12/13 issues closed
- No due date•14/14 issues closed
Right now the web code has a lot of duplication and it's relatively hard to inspect a specific UI component, tweak it, and verify that it looks good. In an ideal state we should be able to: 1. Run `npm run storybook`, then go to the component we're interested in, make changes, and verify visual look and feel in story book. 1. Run a [Jest](https://jestjs.io/) test to verify functionality of a given component. 1. Have minimal amount of duplicate component code that themes, styles, or presents information in the same way. 1. Be able to quickly navigate to the components we're interested in making. To do this, I propose we migrate towards a directory structure modeled by [RedwoodJS](https://redwoodjs.com/): - Directory structure is as follows: * `components/`: All presentation components with a modest amount of nested directory structure. Nested directories should use *lowercase* names. * `layouts/`: Each broad layout component used by pages * `pages`/: What we currently have, user visible pages and API routes. Within a component definition we should then: * Have a folder for the component with the same name. For `MyTaskComponent` it's in `src/components/MyTaskComponent/MyTaskComponent.tsx` * Have a storybook story in the component directory. * Have a Jest test in the component directory. * Have a simple `index.tsx` that exports the component so that call sites can import with `import { MyTaskComponent } from "src/components/MyTaskComponent";` After this change it'll be easier to work on smaller components and test them in isolation without having to actually run the backend in most cases.
No due date•26/29 issues closedThis milestone encapsulates an end to end data gathering process using a live model that users can prompt and interact with. To finish it includes: - [ ] Two or more live models up and running that take a prompt and produce one or more responses - [ ] Some middleware API layer that unifies communication between the live models and keeps secure any API keys - [ ] A user experience that let's a user prompt one or more models and then evaluate the response - [ ] Some kind of data storage process to capture both the prompts, responses, and evaluations with links to the underlying model
No due date•9/10 issues closedThis encapsulates a suite of features for ensuring Open Assistant Admins can manage and modify the data being generated. This should include at a minimum: * A way to specify admin users according to their auth method and external ID * User roles in the website database that gates access to admin and non-admin features * A set of pages limited to those with admin rights the ability to * Upgrade or downgrade the roles of other users * Manage the messages, conversations, and conversation trees created by users
No due date•23/23 issues closed- No due date•152/153 issues closed