|
|
|
# CAB Admin Guide
|
|
|
|
As CAB-Admin you are responsible for the administration of the CAB itself and the assessment framework for the projects. Besides that it is up to you to take care of our community and keep them in a good mood :)
|
|
|
|
|
|
|
|
First of all: A big thank you for your support in our assessment project. We are depending on people like you to get this amazing vision running, so we are really happy to have you with us!
|
|
|
|
|
|
|
|
In this guide we will introduce you to the main tasks you will be able to perform:
|
|
|
|
- [Community Issues](#community-issues)
|
|
|
|
- [Adding a new project](#adding-projects)
|
|
|
|
- [Adding new project members](#adding-members)
|
|
|
|
- [Assessment](#assessment)
|
|
|
|
|
|
|
|
Only need a reminder? Then you might want to jump directly to the [Quick Check](#quick-check) at the end.
|
|
|
|
|
|
|
|
## Community Issues
|
|
|
|
First of all let's start with our most valuable concern, our community. As CAB-Admin you will be one of the contact persons regarding everything around the workflow of the CAB. The workflow depends on the community and the community depends on some caretaking.
|
|
|
|
|
|
|
|
Our community consists of project-developers (applicants for the review), reviewers (proofreading the documentation during the assessment), CAB-developers (working on the workflow development) and lots more.
|
|
|
|
|
|
|
|
### Onboarding
|
|
|
|
The Onboarding makes sure that new members are welcomed and where to find relevant information and how to contribute. There are several possibilites to perform the onboarding:
|
|
|
|
- 1:1 introduction
|
|
|
|
- Small events (for specific groups)
|
|
|
|
- Global events (e.g. during project phases)
|
|
|
|
|
|
|
|
## Adding projects
|
|
|
|
The workflow starts with adding new projects for the review. You will start this process by cloning the project into our repository as described below.
|
|
|
|
|
|
|
|
First of all the [requirements for application](/Documentation/application-guide.md) have to be checked. If everything is fullfilled the project can directly step in the review stage. If there are still open questions the project can be added as development project, helping the applicants to get everything ready for review.
|
|
|
|
|
|
|
|
### Overview
|
|
|
|
Start by adding the project to the [Assessment overview](/archive/assessments.md) and set the status to "development" or "in progress" accordingly (see above). This will show everyone the projects that are or have been undergoing the assessment by OSEGeV.
|
|
|
|
|
|
|
|
Next create an Issue in the [Project Assessment Milestone](https://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/milestones/3) named [Assessment][projectname]. This way our community will have an overview of the projects that are currently perparing for or undergoing assessment.
|
|
|
|
|
|
|
|
If the project is still under development and needs some work until it can be reviewed it should in any case be put to the list (see above).
|
|
|
|
|
|
|
|
Now let's get the project ready:
|
|
|
|
|
|
|
|
### Upload project
|
|
|
|
The projects for reviewing will be uploaded into the [CAB Group](https://gitlab.opensourceecology.de/verein/projekte/cab).
|
|
|
|
Make sure you know where the Project stores its files and get a copy of it.
|
|
|
|
In the simpliest case the project is already uploaded on https://gitlab.opensourceecology.de. This way you can just fork the project into the CAB Group. If not you have to create a local git repository and upload it to our
|
|
|
|
|
|
|
|
**Git Projects**
|
|
|
|
- Save the project locally using `git clone [..]` (e.g. `git clone https://gitlab.com/OSEGermany/ohloom`)
|
|
|
|
**Non-git projects**
|
|
|
|
- Download files and put them in a folder
|
|
|
|
- Make a git repo out of it `git init`
|
|
|
|
**Create Repository**
|
|
|
|
- Create a repository (without readme) under https://gitlab.opensourceecology.de/verein/projekte/cab
|
|
|
|
- Name the project like in original, adding the version number (e.g. Open Hardware Loom v1.0)
|
|
|
|
- Fill the remote repository by changing the upload origin of the local repository
|
|
|
|
|
|
|
|
**Push an existing folder**
|
|
|
|
```
|
|
|
|
cd existing_folder
|
|
|
|
git init
|
|
|
|
git remote add origin ssh://git@gitlab.opensourceecology.de:2222/verein/projekte/cab/ohloom.git
|
|
|
|
git add .
|
|
|
|
git commit -m "Initial commit"
|
|
|
|
git push -u origin main
|
|
|
|
```
|
|
|
|
**Push an existing git repository**
|
|
|
|
```
|
|
|
|
cd existing_repo
|
|
|
|
git remote rename origin old-origin
|
|
|
|
git remote add origin ssh://git@gitlab.opensourceecology.de:2222/verein/projekte/cab/ohloom.git
|
|
|
|
git push -u origin --all
|
|
|
|
git push -u origin --tags
|
|
|
|
```
|
|
|
|
#### Assessment Header
|
|
|
|
Add and fill the [assessment header](/Templates/assessment-header.md) (in Folder [Templates](/Templates)) at the top of the readme file.
|
|
|
|
|
|
|
|
### Projects in Review Stage
|
|
|
|
Projects for assessment will use two different branches. The original files will be in the **main branch**. The assessment will take place in the **review branch**. Once it is finished the review branch will be merged into the main issue using the final tag.
|
|
|
|
```
|
|
|
|
git remote rename master main
|
|
|
|
git checkout -b review
|
|
|
|
```
|
|
|
|
Eventually you may want to protect the reviewer branch, so reviewers (with developer rights) can only enter changes by merge requests. Additionally the release tag can be set as protected.
|
|
|
|
|
|
|
|
#### Add Review Issues
|
|
|
|
Add the Review Issues as described in the [Template Guide](https://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/blob/main/Documentation/issue-templates-guide.md).
|
|
|
|
|
|
|
|
The next step towards the assessment will be to create the initial issues for review. Therefore continue with the [template-guide](/Documentation/issue-templates-guide.md). Eventually you might want to add some members first:
|
|
|
|
|
|
|
|
## Adding members
|
|
|
|
Add new members to the project. Start by adding members as guest in the [CAB Group](https://gitlab.opensourceecology.de/verein/projekte/cab), so they can be found within the sub-projects. The following roles and access rights are used within the CAB:
|
|
|
|
|
|
|
|
- **CAB-Admins**
|
|
|
|
- Tasks: CAB-Administration, Manage Members, Onboarding, Add projects, Add issues, Finalise Assessment
|
|
|
|
- Access rights
|
|
|
|
- CAB Group: Owner (Invite members, Create Subgroups, Set project visibility)
|
|
|
|
- CAB Repo: Maintainer (Administration, Right Management) - inherited
|
|
|
|
- Project Repo: Maintainer (Create, edit, close issues) - inherited
|
|
|
|
- **Reviewer**
|
|
|
|
- Tasks: Durchführen der Reviews, ggf. Anpassungen vorschlagen
|
|
|
|
- Access rights
|
|
|
|
- CAB Group: Guest (Member visibilty)
|
|
|
|
- CAB Repo: Guest (Create issues, comment, create merge requests) - inherited
|
|
|
|
- Project Repo: Developer (create, edit, close issues, create and accept merge requests)
|
|
|
|
- hint: Subgroup Reviewer can be used to give all reviewers automatic access to the project
|
|
|
|
- **Applicants** (at least one)
|
|
|
|
- Tasks: Project contact, bugfixing, create and accept merge requests
|
|
|
|
- Access rights
|
|
|
|
- CAB Group: Guest (Member visibilty)
|
|
|
|
- CAB Repo: Guest (Create issues, comment, create merge requests) - inherited
|
|
|
|
- Project Repo: Developer (create, edit, close issues, create and accept merge requests)
|
|
|
|
- Applicants will be assigned to single projects only
|
|
|
|
- Additonal Developers will be added as applicants
|
|
|
|
- CAB-Entwicklung
|
|
|
|
- Tasks: Development of the Workflow
|
|
|
|
- Access rights
|
|
|
|
- CAB Group: Guest (Member visibilty)
|
|
|
|
- CAB Repo: Reporter (Create issues, comment, create merge requests)
|
|
|
|
|
|
|
|
## Guiding the Assessment
|
|
|
|
As CAB-Admin one of your main responsibility is to observe the assessment process. After creating the templates the review will start. Once all sub-issues are resolved it is up to you to doublecheck if everything was approved by the assigned reviewers. Once this is made sure you can initiate the release.
|
|
|
|
|
|
|
|
Hint: In theory it is possible that some else then the assigend reviewers sets the checkboxes. Although this is very unlikely you will have to make sure that everything was approved accordingly.
|
|
|
|
|
|
|
|
### Assessment Release
|
|
|
|
[ToDo]
|
|
|
|
|
|
|
|
# Quick Check
|
|
|
|
Short checklists for the CAB-Admin tasks.
|
|
|
|
## Add new project
|
|
|
|
- Check [requirements for application](/Documentation/application-guide.md)
|
|
|
|
- Add project in [Assessment overview](/archive/assessments.md)
|
|
|
|
- Create [Assessment][projectname] issue in [Project Assessment Milestone](https://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/milestones/3)
|
|
|
|
- Clone the project into https://gitlab.opensourceecology.de/verein/projekte/cab
|
|
|
|
- (Name the project like in original, adding the version number )
|
|
|
|
- Create and fill the [assessment header](/Templates/assessment-header.md) in the readme
|
|
|
|
- Eventually add new members, then continue with [template-guide](/Documentation/issue-templates-guide.md)
|
|
|
|
|
|
|
|
## Add new member
|
|
|
|
- Send the interested member the member-form and have it filled
|
|
|
|
- Add members as "guest" in the [CAB Group](https://gitlab.opensourceecology.de/verein/projekte/cab)
|
|
|
|
- Add them according to the [Role-Permissions](#adding-members)
|
|
|
|
|
|
|
|
## Assessment
|
|
|
|
[ToDo] |
