How descriptions help Albus:

Descriptions of the sources are just as powerful:

• When you train Albus on a source, he reads through minimal data in the beginning of the source to understand what your source is about.

• In this process, it is possible that he does not understand the full document properly.

• This is when your description of the source will be very useful provided you give a more fuller summary of what the source is about.

• When you ask Albus a question, he will first check all the descriptions of sources and then use that information to search for an answer.

• Unlike connections, you describe a source for all wikis. This is because the content of a source remains the same for all wikis. If someone writes a new description for a source, Albus overwrites the old description.

    Notion:

      Albus already knows Notion allows you to maintain notes, databases, Kanban boards, knowledge bases, company documentation, etc.

• But he does not know how your company specifically uses Notion at work. Perhaps, you use Notion to document all your company policies. Or it is where you post your job openings. Your teams might also be writing product documents and maintain release notes.

• This is where descriptions come handy. When you describe how you use a connection at your workplace, Albus understands how your teams function better.

• When you ask him a question in the future, he will use this description to do much more effective evaluations of where he should look for an answer - a Notion page, a Slack channel, a Jira project or something else.

• You describe a connection for a particular team wiki not for all wikis. This is because you might be using a connection to achieve different goals in different functions.

The key takeaway here is that you must write a highly personalized description of how you use your connections at work. Generic descriptions will not help Albus.

      Here’s a good example of a good description: 
      “We use Notion at work to maintain all our employee documents.

     These include reimbursement  policies, time-off policies, links to employee portals, credentials to corporate accounts on productivity apps

     and more. The HR team also documents all company-wide announcements like townhall events in Notion.”

   Azure DevOps:

1. To enhance Albus's ability to provide accurate and tailored responses, use clear descriptions for your Azure DevOps connections.
2. As your usage of Azure DevOps may differ from other companies, these descriptions help Albus understand your team's unique requirements.
   
3. Below is an example of a good description, which you can modify to fit your Azure DevOps projects. You will also find a list of statuses as used on our JIRA account.
   
4. Your task is to utilize the provided message and status list to detect the status correctly while also identifying other available parameters.
   
5. It is crucial that while answering, you ALWAYS use the JIRA equivalent status mentioned here. If the exact status is not given, then use the status category to choose the closest one but always from the list provided here. Here are the status categories:
   
   

   // IN_PROGRESS:

• Action required, Added to sprint, Assigned, Awaiting Approval, Backlog, Bug opened, Build broken, Building, Contents Team, Design ready, Escalated, Feedback (External), Feedback (Internal), Goldman Sachs Approval, Goldman Sachs test, Goldman Sachs Testing, Implementing, In Progress, In Review, Internal Review, Internal Test, Internal Testing, Investigation, Itemised, Pending, Pending release, Product Team, QA, Ready for Dev, Ready for test, Sent for GS approval, Sent to implementation, Waiting for customer, Waiting for support, With Implementation, With Product

   // TODO:

• Approved for Implementation, Blocked, Blocked (external), Blocked (internal), Completed DPA, New, On hold, Open, Pending response, Pending response/On Hold (IMT), Reopened, Requested, Roadmap, Selected for Development, Submitted, To Do, Waiting for approval, Work in progress

   // DONE:

• Canceled, Closed, Declined, Done, Duplicate, Live, Rejected, Resolved

  By incorporating a detailed description aligned with your Azure DevOps projects, you enhance Albus's ability to deliver accurate and   relevant responses.

Describe sources that are heavy with information. This is when Albus needs as much context as possible about your source. Mention what your source is about, what information it holds and see Albus understand your information better.