gitpoint / gitpoint/git-point

Discussion: Internal - Pull Requests management

Ouverte
#625 9 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
discussion
Langage dominant
JavaScript
Étoiles
4.8k
Forks
771
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

This is an attempt to lay out some ground rules in order to improve our handling of PRs.

Hopefully, this will avoid finding ourselves in the current situation introduced by styled-components PRs.

I believe this should be part of some guidelines documentation once discussed & approved.

### Rules for merging PRs

#### Base rules
* Every person who merges a PR should have tested it by itself on at least one device.
* Every merged PR should have a related issue (merger can create one if needed).
* Never merge your own PRs.

#### Exceptions

* Doc: a PR that only changes documentation files (contributors, readme, ..)
* Typo: a PR that fix a typo in translations or in some variable naming
* QuickFix: a PR that fixes an obvious mistake in js logic causing a know issue (bad if condition, ..)
* Crash: a one-linish PR that fix a crash in master.

Additionally, for those cases, if the person submitting the PR is a maintainer, he can commit directly to master (or merge his own PR without approval).

#### Tests

At some point, we will need to start requiring tests for every significant change.

We still need to have more diversified tests samples available in order to ease the task on the pull requester.

#### Enforcements

* UI: If the PR introduces a new UI, or a change in the UI (styled-components, ..), the PR **should** be tested on both iOS & Android by the person who merges it.
* UI: The PR needs to have screenshots for both Android & iOS. (either the pull-requester or merger should provide them in the discussion)
* i18n: The PR have to be *approved* by at least one native speaker before merge can happen

Guide de contribution

Ouvrir le guide de contribution

Piste de recherche

Commencez par lire la discussion de l’issue et les règles proposées pour merger les pull requests, y compris les exigences concernant les tests, l’UI, les captures d’écran et l’i18n. Aucun point d’entrée de fichier, de test ou de documentation n’est indiqué ; la tâche serait terminée lorsqu’un accord sur les directives serait obtenu et qu’un emplacement de documentation clairement identifié serait défini.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
android, ios, javascript
Domaine
documentation
Type d'issue
Documentation
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.