Dev process

---

layout: page

title: Development

permalink: internal/development-process/dev/development

search: exclude

---

## What ?

## Why ?

## Who ?

| People | Role |

| ------ | ---- |

|        |      |

## How ?

1. The developer works on the issue he is assigned to

2. He starts by creating the MR related to the issue, on the corresponding project. This creation have to be done from the GitLab issue UI. It will give the branch name to use. The MR title have to be pre-fixed by WIP, and the MR template must be filled. The MR is assigned to the developer.

    - the target branch of the MR should be

      - the dev branch if the project has one

      - the sprint branch in other cases

3. The developper starts the dev. For development specification, please refer to each project documentation

4. Once finished or at least once a day for backup reason, the code is pushed to the gitlab branch

5. The apk build by GitLab CI have to be tested, by respecting what is written in the MR description. If the test need to run a complete build, please run a test build, both for you and for the approver(s).

6. If everything is working as expected, remove the WIP status and ask another sprint developer to approve the MR

7. Add test cases into the issue description, and mark is as status::done

The developer assigned to an issue is responsible of it's development.

## Where ?

The GitLab issue

## When ?

Once the developer is assigned to an issue.

---

[Next (Validation) >](validation)

---

layout: page

title: Issue assignment

permalink: internal/development-process/dev/issue-assignment

search: exclude

---

## What ?

This topic discuss of the way for a developer to handle an issue.

## Why ?

The aim is to give some autonomy to developers.

## Who ?

| People | Role |

| ------ | ---- |

|        |      |

## How ?

1. Handle issues that are not assigned to anyone

2. Handle in priority issues from the project you are maintainer onto

3. Handle in priority the issues with the higher priority (P1 > P7)

4. Handle in issues in this order: bug, improvement, new feature

## Where ?

The column **To do** on the sprint board

https://gitlab.e.foundation/groups/e/-/boards/12?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=\<milestone title\>

## When ?

A developer doesn't have any issue assigned to him/her.

---

[Next (Development) >](development)

---

layout: page

title: Validation

permalink: internal/development-process/dev/validation

search: exclude

---

## What ?

Validate the dev done for an issue

## Why ?

Detect as soon as possible errors and give feedbacks to dev

## Who ?

| People | Role |

| ------ | ---- |

|        |      |

## How ?

1. Read the test case describe in the MR

2. Download and install the APK build on GitLab, and validate that it's working as expected

3. Have a look into the code and maybe give feedbacks if needed

4. Once everything is ok, you can approve the MR

5. Once approve, assign again the MR to its author

6. The author is now allowed to merge

7. The issue should be automatically closed

## Where ?

MR

## When ?

When a developer has an MR assign to him which he did not develop

---

[Next (Run the test build) >](../test/run-test-build)

- /e/ version:

- Device model:

- When it started to occur:

- Reproducible with the last /e/ version:

- Reproducible with LineageOS:

## Summary

<Summarize the bug encountered briefly and precisely>

<Please tick one of the following sentences if relevent>

- [ ] The device is unusable

- [ ] The bug is the source of a data loss or a big waste of time

- [ ] The bug concerns a tierce app

- [ ] The bug concerns security

- [ ] The bug concerns privacy

## The problem

**Steps to reproduce**

<How one can reproduce the issue>

**What is the current behavior?**

<What actually happens>

**What is the expected correct behavior?**

<What you should see instead>

## Technical informations

**Relevant logs (`adb logcat`)**

<Paste any relevant logs in the codeblock bellow>

```

```

**Relevant screenshots**

<Screenshots of the problem>

## Solutions

**Workaround**

<To get the feature working or at least to make the device usable>

**Possible fixes**

<Any idea to fix the issue or a link to the line of code that might be the cause for this problem>

/label ~Bug

## Summary

<Summarize the feature briefly and precisely>

**This feature concerns** <Tick at least one of the following choices>

- [ ] UI <Something new in the UI>

- [ ] Behavior <A new behavior to realise something>

- [ ] Privacy <Something that will improve the privacy>

## Description

**Who will use the new feature?**

<Describe the kind of user that want this feature>

**What is the target of the new feature for this user?**

<Describe the result of the feature for the user>

**Why this user would like to use this feature?**

<Describe the reason the user would like this feature>

## Examples

<Give the example of what users will be able to accomplish with the feature>

## Reflection

**Mockups**

**Diagrams**

## Validation

<List test case that will be run to validate that the issue is working as expected>

/label ~"Feature Proposal"