# Atlas Core Structure - Improvement Proposal

This document summarizes the process of improving the Atlas Core Structure - as proposed by @Le_Bateleur (LB). It includes a workflow section, a glosary, and a section on potential bottleneck issues.
Most information was taken from the [*workshop series*](https://forum.makerdao.com/tag/atlas-workshops) hosted by LB and from related forum posts.

## Workflow

### 1) Select High-Priority Articles
What: Articles from the Atlas are chosen by priority criteria. LB mentioned high-priority articles were related to:
- Governance Security
- Resource Deals
- Budgets / Ressource Allocation
Who: LB

### 2) Split Articles into Atomic Sections
What: High-Priority Articles are split into *atomic sections*.
*Atomic sections* are fragments of the article that are limited to defining a single unit of logic.
Each *atomic section* is tagged (?) with a *module*.
Who: LB

### 3) Assign Atomic Sections
What: *Atomic sections* are randomly assigned to the drafters. They receive Google drive folder link.
Who: LB

### 4) Prepare Drafting Plan
What: Each drafter must write a high-level plan describing how they will work on their *atomic section*.
In their plan they should list the *element annotations*, *action tenets*, and *scenarios* that their work will include. They can add a *needed research* section.

When working on an *atomic section* drafters are expected to get familiar with the adjacent sections of the Atlas that could interact with their assigned *atomic section* and with the entire article. Drafters must also consider Next-Generation Atlas Sources (if available), general needs, and supporting documents' needs. The [**heptaboard**](https://app.heptabase.com/w/a5f9a10cd1164b717293d0eed56cb8535c5365e64f9d46ee738cc1424fd7b210?id=9eb37c1c-7c78-46f7-ade3-e71c31b9aefc) created by LB includes all this information for each *atomic section* [??? Or: Drafters must do it and the heptaboard has only one example for A.1.5 ?]

Who: Drafters

### 5) Submit Drafting Plan
What: When the drafting plan is ready, drafters must submit it through this [form](https://form.asana.com/?k=mhDjGu9c5Zl7juR9qcBYwg&d=1206291861940128). The submission will trigger the creation of a new task on LB's calendar.
Who: Drafters

### 6) Greenlight/Stop Drafting Plan
What: Once the drafting plan is submitted, it will be evaluated. If the plan looks like the drafter is on the right direction, it will get approved. Otherwise, the drafter will need to modify it and resubmit.
Generally, plans will be greenlit and comments will be added. Only plans that are too far away from the desired direction will be returned for resubmission.
Who: LB

### 7) Drafting Supporting Docs
What: The supporting documents are drafted following the approved drafting plan.
Drafters work on two Google Docs:
- *Element Annotations*
- *Action tenets*
- *Scenarios*
- *Needed Research*

The Heptaboard specifies whether *element annotations* or *action tenets* are needed for each *atomic section* [???]
Templates to draft *element annotations* and *action tenets* are available on the Google Drive, in the Drafter folder. There is a folder for each article and sub-folders for each *atomic section* with one drafter folder and one reviewer folder.
Visitors with non-Gmail domains receive invite to relevant folders. Every seven days they must verify access.

Examples: XXX [could be nice to include some examples here]

Who: Drafters

### 8) Submit Supporting Docs
What: Drafters use this [form](https://form.asana.com/?k=ru0X7OYeWZ_ovACgOVSMlw&d=1206291861940128) to submit the drafted supporting documents.
Who: Drafters

### 9) Internal Review
What: Feedback loop between LB and drafter done directly on the Google doc. Drafter improves the documents based on feedback until it is considered to be ready for external review.
Who: LB and Drafters

### 10) Convert to JSON
What: Supporting documents that were greenlit following the internal review, are converted to JSON.
Who: ?

### 11) External Review
What: Review the supporting documents that have been internally reviewed and converted to JSON. Provide feedback.
Who: Reviewers

### 12) Reconciliation
What: Supporting documents are modified in order to incorporate feedback from external review.
Who: LB and Drafters

### 13) Merge into Repo
What: Supporting documents modifications are put up to vote and merged into Repo once approved by Maker community.
Who: ?

## Glosary:

- **Article Function**: Supporting document that states the general purpose of an article. It defines what an article should achieve and specifies the articles' *modules*. It provides context and constraints for all Supporting documents.
- **Atomic Section**: Segments of an article that define one single unit of logic. They help distinguish relevant from irrelevant supporting documents of an article.
- **Module**: It is a structural device, not a document of the Atlas. There are several *module classes*, such as powers and constraints, risk management, process definition, stakehold, framework, etc. Modules group *atomic sections* together. Every *atomic section* has a module class and a title.
- **Element Annotation**: Supporting document that limit the semantic range of problematic terms. They define words or concepts that are obscure, vague, or ambiguous, limiting interpretations. They should only be done when words, concepts, or sentences require semantic bounds. They are not an analysis, they should give a succint definition of the ambiguous word/sentence. Not all *atomic sections* will need "element annotations".
- **Action Tenet**: Supporting document that bound the legal meaning of an *atomic section*. They define the elements that trigger actions from Facilitator DAOs to enforce something. Therefore, they should assist Facilitator DAOs to enforce a normative expectation, an authoritative standard. Whenever the *atomic section* includes words like "should", "must", "may", this is a sign that an *action tenet* is needed. They must be as general as possible and only specify exceptions. They should include the rationale (policy justification) to help Facilitator DAOs on edge cases. They should specify criteria for admissibility and relevance of evidence. They must include enforcement methods. Unlike *element annotations*, *action tenets* do not only address one word or concept. They can and should work on what was left unsaid that impacts Facilitator DAO's enforcement of the article. Not all *atomic sections* will need *action tenets*.
- **Scenario**: Real-life situations where the action tenet of an *atomic section* would need to be enforced. Scenarios should be specific. Scenarios can be aligned or misaligned. They are included in the *action tenets*.
- **Needed Research**: Section on the drafting files, not an Atlas document. It intends to keep track of logic gaps that are being found in the process of drafting supporting documents. Drafters are not asked to fill in this field, although they can add information.

## Potential bottleneck issues

- Related to point 1):
- Selecting the high-priority articles is centralized a single community member. This might lead to important articles being left out.
- Related to point 2):
- Splitting the high-priority articles into *atomic sections* is also centralized. Other members of the community could do it differently, leading to considerably different *supporting documents*.
- Since this is an action that determines the whole flow of the drafting work, having diversified members collaborating should be considered. Reviewers could possibly do it.
- Related to point 3)
- Randomly assigning *atomic sections* can have downsides. Drafters are probably more familiar to certain articles and are probably best suited for working on them.
- Taking drafters' preferences into consideration could be valuable.
- Related to point 4)
- Given the fact that drafters are expected to get familiar with the whole article and all relevant sections of the Atlas, having them working on *atomic sections* from multiple articles might slow down the process and fatigue the drafters.
- Making drafters work on *atomic sections* from the same article could be valuable.
- Related to point 6)
- Approving the drafting plan is also centralized. This could lead to ommissions, oversights, misleads.
- A proper drafting plan seems essential to maximize drafters' efficiency. Having more members evaluating and providing feedback to the plan could be beneficial to avoid potential oversights and to speed up the process. Reviewers could possibly do it.
- Related to point 9)
- The internal review process is also centralized.
- Having more community members collaborating with the process could help save time and avoid oversights.
- General:
- A calendar with deadlines would bring value to the process.