forked from TrueCloudLab/frostfs.info
[#9] Update headers levels
This commit is contained in:
parent
0142347054
commit
d35dd93c22
3 changed files with 22 additions and 22 deletions
|
|
@ -14,9 +14,9 @@ unsafe = true
|
|||
|
||||
# table of contents
|
||||
[markup.tableOfContents]
|
||||
endLevel = 5
|
||||
ordered = true
|
||||
startLevel = 3
|
||||
endLevel = 4
|
||||
ordered = false
|
||||
startLevel = 2
|
||||
|
||||
############################# Default Parameters ##########################
|
||||
[params]
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ type: "docs"
|
|||
date: "2022-12-22"
|
||||
---
|
||||
|
||||
### Introduction
|
||||
## Introduction
|
||||
|
||||
|
||||
FrostFS Enhancement Proposals (FEPs) describe standards for the whole FrostFS
|
||||
|
|
@ -18,7 +18,7 @@ never changed.
|
|||
To learn more about the purpose of FEPs and how to go about writing one, please
|
||||
refer to [FEP-1]({{< ref "/proposals/proc/fep-0001" >}}).
|
||||
|
||||
### FEP Status Key
|
||||
## FEP Status Key
|
||||
|
||||
- **Accepted** — Normative proposal accepted for implementation
|
||||
- **Active** — Currently valid informational guidance, or an in-use process
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Date: 2023-04-17
|
|||
toc: true
|
||||
---
|
||||
|
||||
### What is a FEP?
|
||||
## What is a FEP?
|
||||
|
||||
FEP stands for FrostFS Enhancement Proposal. The idea and most of the process is
|
||||
derived from Python [PEP-1](https://www.python.org/dev/peps/pep-0001/). Almost
|
||||
|
|
@ -35,7 +35,7 @@ repository](https://git.frostfs.info/TrueCloudLab/frostfs.info/src/branch/master
|
|||
The current rendered version is available on [frostfs.info
|
||||
site](https://frostfs.info/proposals/).
|
||||
|
||||
### FEP Audience
|
||||
## FEP Audience
|
||||
|
||||
The typical primary audience for FEPs are the FrostFS Core and Service
|
||||
developers, Architecture Committee, as well as developers of applications
|
||||
|
|
@ -46,7 +46,7 @@ However, other parts of the FrostFS community may also choose to use the process
|
|||
to manage complex design coordination problems that require collaboration across
|
||||
multiple projects.
|
||||
|
||||
### FEP Types
|
||||
## FEP Types
|
||||
|
||||
There are three kinds of FEP:
|
||||
|
||||
|
|
@ -70,9 +70,9 @@ There are three kinds of FEP:
|
|||
procedures, guidelines, changes to the decision-making process, and changes
|
||||
to the tools or environment used in FrostFS development.
|
||||
|
||||
### FEP Workflow
|
||||
## FEP Workflow
|
||||
|
||||
#### Starting with an idea
|
||||
### Starting with an idea
|
||||
|
||||
There are several references in this FEP to the "Architecture Committee",
|
||||
"Community Committee", "Committers" and "Developers". The detailed roles and
|
||||
|
|
@ -110,7 +110,7 @@ mentioned above. This gives the author a chance to flesh out the draft FEP to
|
|||
make properly formatted, of high quality, and to address initial concerns about
|
||||
the proposal.
|
||||
|
||||
#### Submitting a FEP
|
||||
### Submitting a FEP
|
||||
|
||||
Following the above initial discussion, the workflow varies based on whether any
|
||||
of the FEP's co-authors are Committers. If one or more of the FEP's co-authors
|
||||
|
|
@ -190,7 +190,7 @@ that at least a prototype implementation be co-developed with the FEP, as ideas
|
|||
that sound good in principle sometimes turn out to be impractical when subjected
|
||||
to the test of implementation.
|
||||
|
||||
#### Discussing a FEP
|
||||
### Discussing a FEP
|
||||
|
||||
As soon as a FEP number has been assigned and the draft FEP is committed to the
|
||||
FEP repository, a discussion thread for the FEP should be created to provide a
|
||||
|
|
@ -219,7 +219,7 @@ FEP review process. Comments, support, concerns and other feedback on this
|
|||
designated thread are a critical part of what the Architecture Committee or
|
||||
FEP-Delegate will consider when reviewing the FEP.
|
||||
|
||||
#### FEP Review & Resolution
|
||||
### FEP Review & Resolution
|
||||
|
||||
Once the authors have completed a FEP, they may request a review for style and
|
||||
consistency from the FEP editors. However, content review and acceptance of the
|
||||
|
|
@ -296,7 +296,7 @@ Some Informational and Process FEPs may also have a status of "Active" if they
|
|||
are never meant to be completed. E.g. [FEP-1]({{< ref "/proposals/proc/fep-0001"
|
||||
>}}) (this FEP :smile:).
|
||||
|
||||
#### FEP Maintenance {#fep_maintenance}
|
||||
### FEP Maintenance {#fep_maintenance}
|
||||
|
||||
In general, FEPs are no longer substantially modified after they have reached
|
||||
the Accepted, Final, Rejected or Superseded state. Once resolution is reached, a
|
||||
|
|
@ -317,7 +317,7 @@ in question.
|
|||
Occasionally, a Deferred or even a Withdrawn FEP may be resurrected
|
||||
with major updates, but it is often better to just propose a new one.
|
||||
|
||||
### What belongs in a successful FEP?
|
||||
## What belongs in a successful FEP?
|
||||
|
||||
Each FEP should have the following parts/sections:
|
||||
|
||||
|
|
@ -394,7 +394,7 @@ Each FEP should have the following parts/sections:
|
|||
Attribution-NonCommercial-ShareAlike 4.0 International License ([CC BY-NC-SA
|
||||
4.0](http://creativecommons.org/licenses/by-nc-sa/4.0/)).
|
||||
|
||||
### FEP Formats and Templates
|
||||
## FEP Formats and Templates
|
||||
|
||||
FEPs are UTF-8 encoded text files using the Markdown format in a dialect used by
|
||||
[Hugo](https://gohugo.io/) static site generator. Markdown allows for rich
|
||||
|
|
@ -404,7 +404,7 @@ functional HTML.
|
|||
The FEP text files are automatically converted to HTML for easier online reading
|
||||
at [FrostFS site](https://frostfs.info/proposals/)
|
||||
|
||||
### FEP Header Preamble {#fep_header_preamble}
|
||||
## FEP Header Preamble {#fep_header_preamble}
|
||||
|
||||
Each FEP must begin with an RFC-2822 style preamble in [Hugo page level
|
||||
params](https://gohugo.io/variables/page/#page-level-params) format. The
|
||||
|
|
@ -475,13 +475,13 @@ rendered obsolete by a later document; the value is the number of the FEP that
|
|||
replaces the current document. The newer FEP must have a Replaces header
|
||||
containing the number of the FEP that it rendered obsolete.
|
||||
|
||||
### Auxiliary Files
|
||||
## Auxiliary Files
|
||||
|
||||
FEPs may include auxiliary files such as diagrams. All support files may be
|
||||
placed in a subdirectory called ``fep-XXXX``, where "XXXX" is the FEP number.
|
||||
When using a subdirectory, there are no constraints on the names used in files.
|
||||
|
||||
### Changing Existing FEPs
|
||||
## Changing Existing FEPs
|
||||
|
||||
Draft FEPs are freely open for discussion and proposed modification, at the
|
||||
discretion of the authors, until submitted to the corresponding Committee for
|
||||
|
|
@ -498,7 +498,7 @@ Guide](https://git.frostfs.info/TrueCloudLab/frostfs.info/blob/master/CONTRIBUTI
|
|||
for additional details, and when in doubt, please check first with the FEP
|
||||
author and/or a FEP editor.
|
||||
|
||||
### Transferring FEP Ownership
|
||||
## Transferring FEP Ownership
|
||||
|
||||
It occasionally becomes necessary to transfer ownership of FEPs to a new
|
||||
champion. In general, it is preferable to retain the original author as a
|
||||
|
|
@ -520,7 +520,7 @@ use email.) If the original author doesn't respond in a timely manner, the
|
|||
Committee will make a unilateral decision (it's not like such decisions can't be
|
||||
reversed :smile:).
|
||||
|
||||
### Committee Responsibilities & Workflow
|
||||
## Committee Responsibilities & Workflow
|
||||
|
||||
A FEP editor must be added to the `@TrueCloudLab/architecture-committee` or
|
||||
`@TrueCloudLab/community-committee` group, depending on the relevant FEP types,
|
||||
|
|
@ -576,7 +576,7 @@ Once the FEP is ready for the repository, a FEP editor will:
|
|||
|
||||
Updates to existing FEPs should be submitted as a pull request.
|
||||
|
||||
### Copyright
|
||||
## Copyright
|
||||
|
||||
This work is licensed under a Creative Commons
|
||||
Attribution-NonCommercial-ShareAlike 4.0 International License.
|
||||
|
|
|
|||
Loading…
Reference in a new issue