From 1f56d0deadc3aaa543ec0196c2ff1bca880e4b7e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20=C4=8Cert=C3=ADk?= Date: Mon, 6 Jan 2020 12:09:48 -0700 Subject: [PATCH] Document workflow based on the discussion in #5 --- WORKFLOW.md | 38 +++++++++++++++++++++++++++++++++++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/WORKFLOW.md b/WORKFLOW.md index 8c1672af4..354b33c2d 100644 --- a/WORKFLOW.md +++ b/WORKFLOW.md @@ -1,5 +1,37 @@ # Workflow for the Fortran stdlib contributors -This document will describe the workflow we'll follow when developing the Fortran stdlib. -It's largely to be discussed and decided. -For now, take a look at the [issues](https://github.com/fortran-lang/stdlib). +This document describes our current workflow. You are welcome to propose +changes in it by opening an +[issue](https://github.com/fortran-lang/stdlib/issues). + +1. You have an idea or a proposal. Open an issue to discuss it. This is on the + level of "is there interest in having image reader/writer functions in + stdlib?" + +2. When there seems to be significant interest in the proposal, like 80/20 + participants think it's a good/bad idea, move on to discuss the specific + API. It's OK to propose the API off the bat if you already have an idea for + it. + +3. Discuss the API and iterate. When there is ~80/20 approval for the API, move + on to implement it and submit a PR. Small PRs are always better than large. + It's OK to implement only a few functions of a new module, and continue work + on the others in a later PR. All new functionality goes into an + "experimental" namespace (`stdlib_experimental_*.f90`). + +4. When opening a PR, request reviews from one or more people that are most + relevant to it. These are likely to be people involved in prior steps of the + workflow. Other contributors (not explicitly invited) are encouraged to + provide reviews and suggestions as well. Iterate until all (or most) + participants are on the same page. We should not merge if there is a strong + objection from the reviewers or from somebody in the wider community. + +5. Moving from experimental to main. Once new functionality lands into + "experimental", the next step is to write a "specification". The + specification is a document that describes the API and the functionality, so + that anyone can use it to create an implementation from scratch without + looking at `stdlib`. `stdlib` provides the reference implementation. When + this specification document is approved by the wide community and the + standards committee (informally), then we can move the code into main, and + the particular specification document becomes part of the Fortran Standard + Library.