Define and scope context for GitLab Duo
The problem
Value proposition: One of the unique advantages of GitLab in AI is its potential to deliver value for the entire DevSecOps space. This value can come in many forms like convenience, confidence, and capability, but much of those are derived from or dependent on context. By leveraging the available context of the platform we can avoid the "cold start problem" and meet the user expectation that the AI will have awareness of the assets and information. This allows context to become the "connective tissue of the SDLC".
To accomplish we need to define a strategy to allow the system to provide context in a way that provides value while maintaining security and aligns with user expectations/needs.
Goals
- Gather and share relevant information
- Facilitate collaboration and discussion
- Scope, breakdown, and prioritize potential areas to pursue
Potential areas of focus
Sensible defaults: The system should meet user expectations "out of the box" without needing extensive configuration to provide baseline context to a given task or flow. A lot of work has already been done in this area, but there may be room for continued improvements and alignment as new features are added.
User awareness of context: Helping users understand what context is being provided will help set expectations of results.
Control context: Allowing users to control the context provided can help meet privacy and security concerns and tailor the experience to meet their personal, company, or project goals. It also allows users to deviate from defaults in situations where a particular set of context is more helpful than general context
Manage context: Similar to above but focused more on safeguards, boundaries, and policies related to context.
History and Memory: As users progress through tasks the historical context can be an important predictor of future actions. By leveraging history as context we may be able to provide better results on the users' current task.
Sync context to user flow: As users change or progress through tasks, their contextual needs change. We need to make sure the context is updated to match where they are in a flow. This can become important as a user navigates through the product, changes files or folders in an IDE, changes projects, groups, etc.
Related context: Context related to the user task but not directly part of it can add additional information that is likely to produce better results and could delight users. Examples could include awareness of a related issue in a merge request, files referenced or referenced by the current file being worked on, related issues either explicitly related or "related by AI", and issues in epics relating to the epic itself.
Potential solutions
- Documentation to describe sensible defaults
- UI to display context provided by sensible defaults
- UI to manage defaults
- UI to change the current context
- @ mention ( or other) to manage context
- UI displaying sources used in generating response (existing today but might need additional work from additional types of sources)
- UI to see memory/historical context
- Add an indication of the page/IDE etc that a chat took place in
- UI to manage single chat across pages/IDE or allow threading
- UI manages memory/historical context (ie to clear it)
- Add the ability to create a set of context
- Add the ability to use set/change sets of context
- Add the ability to add in one-off context
- Add the ability to add related items as context
- Add the ability to designate project files or folders as context (For example a coding style guide)
- Add the ability to create a personal context to allow users to make the system perform the way they prefer to.
- Add the ability to designate how context should be used (purpose)
⭐ - Add the ability manage or switch between conversations