mirror of
https://github.com/bakhirev/assayo.git
synced 2024-11-16 08:11:40 +00:00
update
This commit is contained in:
parent
68d3283497
commit
af1ae2a92f
162
documents/DE.md
Normal file
162
documents/DE.md
Normal file
|
@ -0,0 +1,162 @@
|
||||||
|
> - [Русский](https://github.com/bakhirev/assayo/blob/main/documents/RU.md)
|
||||||
|
> - [English](https://github.com/bakhirev/assayo)
|
||||||
|
> - [中文](https://github.com/bakhirev/assayo/blob/main/documents/ZH.md)
|
||||||
|
> - [Español](https://github.com/bakhirev/assayo/blob/main/documents/ES.md)
|
||||||
|
> - [Français](https://github.com/bakhirev/assayo/blob/main/documents/FR.md)
|
||||||
|
> - [Português](https://github.com/bakhirev/assayo/blob/main/documents/PT.md)
|
||||||
|
> - [Deutsch](https://github.com/bakhirev/assayo/blob/main/documents/DE.md)
|
||||||
|
> - [日本語](https://github.com/bakhirev/assayo/blob/main/documents/JA.md)
|
||||||
|
|
||||||
|
# [Assayo](https://assayo.jp/?ref=github&lang=ru)
|
||||||
|
|
||||||
|
Visualisierung und analyse ihrer Git-datenbank ([demo](https://assayo.jp/demo/?dump=./test.txt&lang=ru)).
|
||||||
|
|
||||||
|
##### Mitarbeiter können den neuen arbeitsplatz bewerten
|
||||||
|
- arbeitsgeschwindigkeit;
|
||||||
|
- anzahl der überstunden;
|
||||||
|
- verantwortungsbereiche;
|
||||||
|
- umfang des neuen funktionsweise und fehlerbestandes;
|
||||||
|
- arbeitsstil der kollegen;
|
||||||
|
|
||||||
|
##### Der vorgesetzte kann die mitarbeiter bewerten
|
||||||
|
- ermitteln sie die untätigen;
|
||||||
|
- schätzen sie den codeumfang ab;
|
||||||
|
- erfahren sie die arbeitsgeschwindigkeit;
|
||||||
|
- merken sie verhaltensanomalien;
|
||||||
|
- beobachten sie das arbeitsgeschehen nach wochen;
|
||||||
|
|
||||||
|
##### Der Investor kann das produkt bewerten
|
||||||
|
- produktpreis;
|
||||||
|
- preis des neuen funktionsumfanges;
|
||||||
|
- entwicklungszeit;
|
||||||
|
- vorhersage der zeit für überarbeitungen;
|
||||||
|
- preiskostenprognose;
|
||||||
|
|
||||||
|
### Wie kann ich die Anzahl der Commits schnell sehen?
|
||||||
|
|
||||||
|
In der wurzelverzeichnis ihres projektes muss der befehl ausgeführt werden:
|
||||||
|
```
|
||||||
|
git shortlog -s -n -e
|
||||||
|
```
|
||||||
|
### Wie kann ich Autoren zusammenbringen?
|
||||||
|
Sie müssen eine datei im stammverzeichnis ihres projekts erstellen `.mailmap`.
|
||||||
|
Beispiel für den Inhalt einer Datei:
|
||||||
|
```
|
||||||
|
Alex B <alex@mail.uk>
|
||||||
|
Alex B <alex@mail.uk> <alex@gov.tk>
|
||||||
|
Alex B <alex@mail.uk> <bakhirev@ya.kz>
|
||||||
|
Alex B <alex@mail.uk> <man64@yahoo.com>
|
||||||
|
```
|
||||||
|
Sie können mehr über das format dieser datei lesen[hier](https://git-scm.com/docs/gitmailmap).
|
||||||
|
|
||||||
|
### Wie kann ich Daten aus git?
|
||||||
|
|
||||||
|
#### Für die onlineansicht
|
||||||
|
In der wurzelverzeichnis ihres projektes ausführen:
|
||||||
|
```
|
||||||
|
git --no-pager log --numstat --oneline --all --reverse --date=iso-strict --pretty=format:"%ad>%cN>%cE>%s" > log.txt
|
||||||
|
```
|
||||||
|
#### Zum Surfen ohne Internet
|
||||||
|
|
||||||
|
```
|
||||||
|
git --no-pager log --numstat --oneline --all --reverse --date=iso-strict --pretty=format:"%ad>%cN>%cE>%s" | sed -e 's/\\/\\\\/g' | sed -e 's/`/"/g' | sed -e 's/^/report.push(\`/g' | sed 's/$/\`\);/g' | sed 's/\$/_/g' > log.txt
|
||||||
|
```
|
||||||
|
Git erstellt eine datei `log.txt`.
|
||||||
|
Diese datei enthält die daten zum erstellen des berichts.
|
||||||
|
|
||||||
|
Der unterschied zwischen den formaten liegt im vorhandensein einer wrapper für zeilen. Das format ohne internet wird wie eine js-datei geladen, wenn sie es einfach öffnen. `/build/index.html`
|
||||||
|
|
||||||
|
### Wie kann ich den bericht mit dem internet anzeigen?
|
||||||
|
|
||||||
|
- gehe zu [Webseite](https://assayo.jp/)
|
||||||
|
- den knopf drücken “[Demonstration](https://assayo.jp/demo?lang=ru)”
|
||||||
|
- datei ziehen `log.txt` in das Browserfenster
|
||||||
|
|
||||||
|
### Wie kann ich einen Bericht ohne Internet anzeigen?
|
||||||
|
- laden sie dieses repository herunter
|
||||||
|
- datei ziehen `log.txt` in den ordner`/build`
|
||||||
|
- starten `/build/index.html`
|
||||||
|
- oder ziehen sie einen ordner `/build` zu sich ins repository (der ort, an dem es liegt `log.txt`). Sie können den namen ändern. zum beispiel mit dem namen `/build` auf den namen `/report`
|
||||||
|
|
||||||
|
Es ist wichtig, dass die log.txt datei vom befehl für die offlineansicht erstellt wird.
|
||||||
|
|
||||||
|
### Wie kann ich die Berichtsdatei neu erstellen?
|
||||||
|
- Laden Sie dieses Repository herunter
|
||||||
|
- Erfüllen `npm install`
|
||||||
|
- Erfüllen `npm run build`
|
||||||
|
- Der neue Build wird im Ordner sein `/build`
|
||||||
|
|
||||||
|
### Wie kann ich den bericht zur microservices-gruppe anzeigen?
|
||||||
|
- Datei für jeden microservice generieren `log.txt` (`log-1.txt`, `log-2.txt`, `log-3.txt` usw.)
|
||||||
|
- Siehe “Wie kann ich den bericht mit internet ansehen?”. Im letzten schritt ziehen sie alle dateien gleichzeitig in das browserfenster.
|
||||||
|
- Siehe “Wie kann man den bericht ohne internet ansehen?” Im zweiten schritt ziehen sie die microservice-dateien alle (`log-1.txt`, `log-2.txt`, `log-3.txt` usw.) in den berichtsordner (`/build`).
|
||||||
|
|
||||||
|
### Wie kann ich die benutzeroberfläche in ihren markenfarben neu streichen?
|
||||||
|
Sie können ihr skin für die schnittstelle schreiben. Kann geändert werden:
|
||||||
|
- **Überschrift**. Sie können es im URL-parameter angeben ```title```. Zum beispiel: ```?title=you company```
|
||||||
|
- **CSS Stile**. Um dies zu tun, müssen sie die CSS-datei vorbereiten und ihre adresse im URL-parameter angeben ```theme```. Zum beispiel: ```?theme=//company.com/some.css```. Sie können klassennamen als selektoren verwenden. Die meisten von ihnen ändern sich nicht, wenn eine neue version veröffentlicht wird.
|
||||||
|
- **Sprache**. Sie können es im URL-parameter angeben ```lang```. Zum Beispiel: ```?lang=es```
|
||||||
|
|
||||||
|
### Wie signiere ich commits?
|
||||||
|
|
||||||
|
Folge der praxis [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/). Zum beispiel:
|
||||||
|
```
|
||||||
|
JIRA-1234 feat(profile): added avatar for user
|
||||||
|
```
|
||||||
|
- aufgabennummer `(JIRA-1234)`
|
||||||
|
- art der arbeit `(feat, fix, style, refactor, test, doc usw.)`
|
||||||
|
- arbeitsbereich `(profile - ein abschnitt der website, eine seite oder eine neue funktionalität, mit einem wort)`
|
||||||
|
- beschreibung der arbeit `(added avatar for user)`
|
||||||
|
|
||||||
|
### Wie kann ich die Datenerfassung automatisieren?
|
||||||
|
|
||||||
|
#### Kein bekend
|
||||||
|
- erstellen sie einen klon ihres repositorys;
|
||||||
|
- kopieren sie den ordner `build` aus dem aktuellen repository;
|
||||||
|
- öffnen `build/index.html` im browser und zu lesezeichen hinzufügen;
|
||||||
|
- fügen sie eine verknüpfung hinzu `build/assets/ci-cd.sh` in den startordner (windows);
|
||||||
|
|
||||||
|
Jedes mal, wenn der computer neu gestartet wird, aktualisiert das skript die statistiken für alle daten, die automatisch in den hauptzweig aufgenommen wurden.
|
||||||
|
|
||||||
|
### DevOps (CI/CD)
|
||||||
|
|
||||||
|
#### Öffentlicher server
|
||||||
|
|
||||||
|
Sie können eine datendatei zum erstellen eines berichts auf eine öffentliche URL hochladen. Sie können die Website verwenden, um sie zu visualisieren [assayo](https://assayo.jp/). Geben sie im URL-parameter die adresse an, an der die daten liegen ```dump```:
|
||||||
|
```
|
||||||
|
https://assayo.jp/demo/?dump=//you_site.com/some/log.txt
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Privater server
|
||||||
|
- herunterladen [docker das bild](https://hub.docker.com/r/bakhirev/assayo);
|
||||||
|
- führen Sie es im lokalen netzwerk aus;
|
||||||
|
- um berichte anzuzeigen, verwenden sie die webschnittstelle, um die adresse anzugeben, an der sich die daten befinden, im URL-parameter ```dump```:
|
||||||
|
```
|
||||||
|
http://assayo_url/?dump=//you_url/some/log.txt
|
||||||
|
assayo_url - die adresse des assayo-containers, er hört auf port 80;
|
||||||
|
you_url - URL die adresse ihres containers mit git-logs;
|
||||||
|
```
|
||||||
|
|
||||||
|
Standardmäßig wird das abbild an der folgenden adresse ausgeführt ```http://127.0.0.1:80/```. Wenn es nicht funktioniert, überprüfen sie, ob der port 80 frei ist.
|
||||||
|
#### Aktualisieren eines Docker-Images
|
||||||
|
|
||||||
|
- befehl ausführen ```npm run build```
|
||||||
|
- befehl ausführen ```docker build -t assayo .```
|
||||||
|
- ergebnis überprüfen ```docker run --name assayo -p 80:80 -d assayo```;
|
||||||
|
- befehl ausführen ```docker tag IMAGE_ID bakhirev/assayo:latest```;
|
||||||
|
- senden sie ein containerimage an Docker Hub
|
||||||
|
|
||||||
|
### Veröffentlichungen, ungefähr alle sechs monate. Was weiter:
|
||||||
|
|
||||||
|
Schau [hauptdokumentation](https://github.com/bakhirev/assayo/blob/main/documents/RU.md)
|
||||||
|
|
||||||
|
### Wie kann ich eine übersetzung hinzufügen oder bearbeiten?
|
||||||
|
|
||||||
|
Sie können eine neue übersetzung hinzufügen oder die aktuelle im abschnitt korrigieren ```ts/translations/```.
|
||||||
|
[Anleitung](https://docs.github.com/ru/get-started/exploring-projects-on-github/contributing-to-a-project)
|
||||||
|
|
||||||
|
### Wünsche, Anregungen, Kommentare
|
||||||
|
- telegramm [@bakhirev](https://t.me/bakhirev) (vorrangiger Kommunikationsweg)
|
||||||
|
- [alexey-bakhirev@yandex.ru](mailto:alexey-bakhirev@yandex.ru)
|
||||||
|
- сайт [https://assayo.jp/](https://assayo.jp/)
|
||||||
|
|
|
@ -71,7 +71,7 @@ La différence entre le format en ligne et le format hors ligne réside dans l
|
||||||
### Comment voir le rapport en ligne?
|
### Comment voir le rapport en ligne?
|
||||||
|
|
||||||
- Aller à [сайт](https://assayo.online/)
|
- Aller à [сайт](https://assayo.online/)
|
||||||
- Appuyer sur le bouton «[Démo](https://assayo.online/demo)»
|
- Appuyer sur le bouton “[Démo](https://assayo.online/demo)”
|
||||||
- Faites glisser le fichier `log.txt` dans la fenêtre du navigateur
|
- Faites glisser le fichier `log.txt` dans la fenêtre du navigateur
|
||||||
|
|
||||||
### Comment voir le rapport hors ligne?
|
### Comment voir le rapport hors ligne?
|
||||||
|
@ -90,8 +90,8 @@ Dans cette cas, il est important que le fichier log.txt ait été généré par
|
||||||
|
|
||||||
### Comment voir le compte rendu pour un groupe de microservices?
|
### Comment voir le compte rendu pour un groupe de microservices?
|
||||||
- générer un fichier pour chaque microservice `log.txt` (`log-1.txt`, `log-2.txt`, `log-3.txt` etc.)
|
- générer un fichier pour chaque microservice `log.txt` (`log-1.txt`, `log-2.txt`, `log-3.txt` etc.)
|
||||||
- Voir «Comment voir le rapport en ligne?». Au dernier pas, glisser tous les fichiers dans la fenêtre du navigateur.
|
- Voir “Comment voir le rapport en ligne?”. Au dernier pas, glisser tous les fichiers dans la fenêtre du navigateur.
|
||||||
- Voir «Comment regarder le rapport hors-ligne?». Au deuxième pas, coller tous les fichier de microservices (`log-1.txt`, `log-2.txt`, `log-3.txt` etc.) dans le dossier du rapport (`/build`).
|
- Voir “Comment regarder le rapport hors-ligne?”. Au deuxième pas, coller tous les fichier de microservices (`log-1.txt`, `log-2.txt`, `log-3.txt` etc.) dans le dossier du rapport (`/build`).
|
||||||
|
|
||||||
### Comment apposer une marque sur l’interface?
|
### Comment apposer une marque sur l’interface?
|
||||||
Vous pouvez écrire votre propre thème pour l’interface. Vous pouvez changer :
|
Vous pouvez écrire votre propre thème pour l’interface. Vous pouvez changer :
|
||||||
|
|
92
src/ts/translations/de/achievements.ts
Normal file
92
src/ts/translations/de/achievements.ts
Normal file
|
@ -0,0 +1,92 @@
|
||||||
|
export default `
|
||||||
|
§ achievements.commitsAfter1500.title: Owl
|
||||||
|
§ achievements.commitsAfter1500.description: 70% of commits after 3:00 PM
|
||||||
|
§ achievements.commitsBefore1500.title: Early bird
|
||||||
|
§ achievements.commitsBefore1500.description: 70% of commits before noon
|
||||||
|
§ achievements.workEveryTime.title: Devoted worker
|
||||||
|
§ achievements.workEveryTime.description: a commit for every hour of the day
|
||||||
|
§ achievements.workNotWork.title: Shooting blanks
|
||||||
|
§ achievements.workNotWork.description: commits are there, but no tasks are closed
|
||||||
|
§ achievements.userNotWork.title: Fly-by
|
||||||
|
§ achievements.userNotWork.description: this is not their main project
|
||||||
|
§ achievements.userIsDied.title: Dead soul
|
||||||
|
§ achievements.userIsDied.description: worked, but resigned
|
||||||
|
§ achievements.lessTasks.title: Came and went
|
||||||
|
§ achievements.lessTasks.description: least closed tasks
|
||||||
|
§ achievements.moreTasks.title: Father says well done
|
||||||
|
§ achievements.moreTasks.description: most closed tasks
|
||||||
|
§ achievements.everyMessageLong.title: Master of eloquence
|
||||||
|
§ achievements.everyMessageLong.description: consistently the longest commit messages
|
||||||
|
§ achievements.everyMessageShort.title: Talkative, a spy's dream
|
||||||
|
§ achievements.everyMessageShort.description: consistently, the shortest commit messages
|
||||||
|
§ achievements.shortestName.title: Size doesn't matter
|
||||||
|
§ achievements.shortestName.description: shortest name
|
||||||
|
§ achievements.longestName.title: Azim Aziz Il Am Kadir Imran II
|
||||||
|
§ achievements.longestName.description: longest name
|
||||||
|
§ achievements.moreCommits.title: Backup master
|
||||||
|
§ achievements.moreCommits.description: most commits
|
||||||
|
§ achievements.lessCommits.title: Rare but Precise
|
||||||
|
§ achievements.lessCommits.description: least commits
|
||||||
|
§ achievements.oneCommitOneTask.title: Right on target
|
||||||
|
§ achievements.oneCommitOneTask.description: on average one commit per task
|
||||||
|
§ achievements.moreLazyDays.title: With you in spirit
|
||||||
|
§ achievements.moreLazyDays.description: most days without commits
|
||||||
|
§ achievements.lessLazyDays.title: Papa carlo
|
||||||
|
§ achievements.lessLazyDays.description: least days without commits
|
||||||
|
§ achievements.zeroLazyDays.title: Not a single break
|
||||||
|
§ achievements.zeroLazyDays.description: not a single day without commits
|
||||||
|
§ achievements.moreWorkDays.title: Valuable employee
|
||||||
|
§ achievements.moreWorkDays.description: most working days
|
||||||
|
§ achievements.moreScopes.title: Startuper
|
||||||
|
§ achievements.moreScopes.description: completed the most features
|
||||||
|
§ achievements.lessScopes.title: Dandy
|
||||||
|
§ achievements.lessScopes.description: completed the fewest features
|
||||||
|
§ achievements.moreDaysForTask.title: Snail on the slope
|
||||||
|
§ achievements.moreDaysForTask.description: tasks take longer than others
|
||||||
|
§ achievements.more2DaysForTask.title: Slow and steady
|
||||||
|
§ achievements.more2DaysForTask.description: more than two days per task
|
||||||
|
§ achievements.moreDaysInProject.title: Old-timer
|
||||||
|
§ achievements.moreDaysInProject.description: most days in the project
|
||||||
|
§ achievements.lessDaysInProject.title: And who is this?
|
||||||
|
§ achievements.lessDaysInProject.description: least days in the project
|
||||||
|
§ achievements.more90DaysInProject.title: Welcome aboard
|
||||||
|
§ achievements.more90DaysInProject.description: not fired during the probation period
|
||||||
|
§ achievements.lessDaysForTask.title: Quick draw
|
||||||
|
§ achievements.lessDaysForTask.description: a task takes less than a day
|
||||||
|
§ achievements.adam.title: Adam
|
||||||
|
§ achievements.adam.description: the first stable employee on the project
|
||||||
|
§ achievements.more666DaysInProject.title: Devil
|
||||||
|
§ achievements.more666DaysInProject.description: worked 666 days on the project
|
||||||
|
§ achievements.more777DaysInProject.title: Azino three axes
|
||||||
|
§ achievements.more777DaysInProject.description: worked 777 days on the project
|
||||||
|
§ achievements.moreRefactoring.title: Executive editor
|
||||||
|
§ achievements.moreRefactoring.description: made the most 'refactoring' tags
|
||||||
|
§ achievements.longestMessage.title: So many conversations...
|
||||||
|
§ achievements.longestMessage.description: the longest commit message of all time
|
||||||
|
§ achievements.moreTasksInDay.title: Speed racer
|
||||||
|
§ achievements.moreTasksInDay.description: record for the number of tasks closed in a day
|
||||||
|
§ achievements.hasCommitFrom0to7.title: Night watch
|
||||||
|
§ achievements.hasCommitFrom0to7.description: a commit for every hour of the night
|
||||||
|
§ achievements.noCommitOnDay.title: Technical break
|
||||||
|
§ achievements.noCommitOnDay.description: there is a certain hour and day in working time when never commits
|
||||||
|
§ achievements.hasCommitEveryTime.title: Died at work
|
||||||
|
§ achievements.hasCommitEveryTime.description: a commit for every hour of each day (including weekends)
|
||||||
|
§ achievements.commitsAfter1800.title: Business Time
|
||||||
|
§ achievements.commitsAfter1800.description: no commits after 6:00 PM
|
||||||
|
§ achievements.more1488DaysInProject.title: Named after Maxim Martsinkevich
|
||||||
|
§ achievements.more1488DaysInProject.description: worked 1488 days on the project
|
||||||
|
§ achievements.moreFix.title: Bug hunter
|
||||||
|
§ achievements.moreFix.description: most closed bugs
|
||||||
|
§ achievements.lessWorkDays.title: Count me out
|
||||||
|
§ achievements.lessWorkDays.description: least working days
|
||||||
|
§ achievements.moreCreateCode.title: Creator
|
||||||
|
§ achievements.moreCreateCode.description: tends to add code more than others
|
||||||
|
§ achievements.moreRemoveCode.title: Destroyer
|
||||||
|
§ achievements.moreRemoveCode.description: tends to remove code more than others
|
||||||
|
§ achievements.moreChangeCode.title: Reformer
|
||||||
|
§ achievements.moreChangeCode.description: tends to change code more than others
|
||||||
|
§ achievements.moreStyle.title: Fashion police
|
||||||
|
§ achievements.moreStyle.description: tends to change CSS more than others
|
||||||
|
§ achievements.moreOnHoliday.title: No life
|
||||||
|
§ achievements.moreOnHoliday.description: relatively many commits in non-working hours
|
||||||
|
`;
|
27
src/ts/translations/de/common.ts
Normal file
27
src/ts/translations/de/common.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ uiKit.console.button: Kopieren
|
||||||
|
§ uiKit.console.notification: Der Text wurde kopiert
|
||||||
|
§ uiKit.dataLoader.page: Seite
|
||||||
|
§ uiKit.dataLoader.size: Wird nach angezeigt
|
||||||
|
§ uiKit.dataLoader.from: aus
|
||||||
|
§ uiKit.dataLoader.all: Alles anzeigen
|
||||||
|
§ uiKit.hoursChart.work: normale Arbeitszeit (wochentags von 07:00 bis 20:00 Uhr)
|
||||||
|
§ uiKit.hoursChart.weekend: wochenenden oder Zeit vor/nach dem Arbeitstag
|
||||||
|
§ uiKit.hoursChart.days: gesamtzahl der Commits für die gesamte Zeit an einem bestimmten Tag und einer bestimmten Stunde
|
||||||
|
§ uiKit.page.remove: Entfernen
|
||||||
|
§ uiKit.nothingFound.common.title: Es gibt keine oder nicht genügend Daten zum Anzeigen
|
||||||
|
§ uiKit.nothingFound.common.description: Das System verarbeitet mehr Daten, wenn die Commits im Format signiert werden [Git commit message convention|https://www.conventionalcommits.org/en/v1.0.0/]. Vorlage:
|
||||||
|
§ uiKit.nothingFound.common.console: Aufgabennummer Typ(Module): Erläuterung
|
||||||
|
§ uiKit.nothingFound.common.example: Zum Beispiel:
|
||||||
|
§ uiKit.nothingFound.staff.title: Keine Daten für diesen Mitarbeiter
|
||||||
|
§ uiKit.nothingFound.staff.description1:
|
||||||
|
Er hat nicht an allen Werktagen Änderungen vorgenommen. Deshalb erhielt er den Status "Assistent".
|
||||||
|
Die Statistiken eines Mitarbeiters mit diesem Status können nicht berücksichtigt werden. Sein Beitrag ist gering.
|
||||||
|
§ uiKit.nothingFound.staff.description2:
|
||||||
|
Das System berechnet für ihn keine Anzahl von Indikatoren.
|
||||||
|
Wenn dies ein Fehler ist und die Statistiken für diesen Mitarbeiter berücksichtigt werden müssen, gehen Sie zu «Einstellungen» und ändern Sie den Typ des Mitarbeiters.
|
||||||
|
§ common.title: Git Statistik
|
||||||
|
§ common.filters: Filter
|
||||||
|
§ common.notifications.save: Änderungen gespeichert
|
||||||
|
§ common.notifications.setting: Einstellungen gespeichert
|
||||||
|
`;
|
15
src/ts/translations/de/index.ts
Normal file
15
src/ts/translations/de/index.ts
Normal file
|
@ -0,0 +1,15 @@
|
||||||
|
import achievements from './achievements';
|
||||||
|
import common from './common';
|
||||||
|
import navigation from './navigation';
|
||||||
|
import recommendations from './recommendations';
|
||||||
|
import settings from './settings';
|
||||||
|
import pages from './pages';
|
||||||
|
|
||||||
|
export default [
|
||||||
|
achievements,
|
||||||
|
common,
|
||||||
|
navigation,
|
||||||
|
recommendations,
|
||||||
|
settings,
|
||||||
|
pages,
|
||||||
|
].join('');
|
40
src/ts/translations/de/navigation.ts
Normal file
40
src/ts/translations/de/navigation.ts
Normal file
|
@ -0,0 +1,40 @@
|
||||||
|
export default `
|
||||||
|
§ sidebar.switch.team: Das Team
|
||||||
|
§ sidebar.switch.person: Der Angestellte
|
||||||
|
§ sidebar.buttons.settings: Die Einstellungen
|
||||||
|
§ sidebar.buttons.print: Drucken
|
||||||
|
§ sidebar.filters.all: Die ganze Zeit
|
||||||
|
§ sidebar.filters.year: Jahr
|
||||||
|
§ sidebar.filters.halfYear: ein halbes Jahr
|
||||||
|
§ sidebar.filters.month: Monat
|
||||||
|
§ sidebar.filters.week: die Woche
|
||||||
|
§ sidebar.team.total: Allgemeine Informationen
|
||||||
|
§ sidebar.team.scope: Module
|
||||||
|
§ sidebar.team.author: Mitarbeiter
|
||||||
|
§ sidebar.team.type: Aufgabentypen
|
||||||
|
§ sidebar.team.pr: Code einfüllen
|
||||||
|
§ sidebar.team.day: Tageweise
|
||||||
|
§ sidebar.team.week: Nach Wochen
|
||||||
|
§ sidebar.team.month: Nach Monaten
|
||||||
|
§ sidebar.team.tree: Analysieren von Dateien
|
||||||
|
§ sidebar.team.files: Dateien
|
||||||
|
§ sidebar.team.removedFiles: Gelöschte Dateien
|
||||||
|
§ sidebar.team.tasks: Aufgabenliste
|
||||||
|
§ sidebar.team.hours: Zeitplan
|
||||||
|
§ sidebar.team.commits: All commits
|
||||||
|
§ sidebar.team.changes: Alle Änderungen
|
||||||
|
§ sidebar.team.words: Beliebte Wörter
|
||||||
|
§ sidebar.team.top: Quiz
|
||||||
|
§ sidebar.team.settings: Die Einstellungen
|
||||||
|
§ sidebar.person.total: Allgemeine Informationen
|
||||||
|
§ sidebar.person.money: Arbeitskosten
|
||||||
|
§ sidebar.person.speed: Geschwindigkeit
|
||||||
|
§ sidebar.person.day: Tageweise
|
||||||
|
§ sidebar.person.week: Nach Wochen
|
||||||
|
§ sidebar.person.month: Nach Monaten
|
||||||
|
§ sidebar.person.hours: Zeitplan
|
||||||
|
§ sidebar.person.commits: All commits
|
||||||
|
§ sidebar.person.changes: Alle Änderungen
|
||||||
|
§ sidebar.person.words: Beliebte Wörter
|
||||||
|
§ sidebar.person.settings: Die Einstellungen
|
||||||
|
`;
|
212
src/ts/translations/de/pages.ts
Normal file
212
src/ts/translations/de/pages.ts
Normal file
|
@ -0,0 +1,212 @@
|
||||||
|
export default `
|
||||||
|
§ page.welcome.step1: Execute the command in the root of your project.
|
||||||
|
§ page.welcome.step3: Drag and drop
|
||||||
|
§ page.welcome.step4: the log.txt file onto this page.
|
||||||
|
§ page.welcome.description: Git will create a log.txt file. It contains data for report generation. Or use git shortlog -s -n -e if you don't need a report. Create a [.mailmap|https://git-scm.com/docs/gitmailmap] file in the root of the project to consolidate employee statistics.
|
||||||
|
§ page.welcome.warning1: The service *DOES NOT SAVE* and *DOES NOT TRANSFER* your data. All calculations are performed locally in your browser on your machine.
|
||||||
|
§ page.welcome.warning2: The service *DOES NOT COLLECT STATISTICS* on projects. You can disconnect the internet, check traffic, and even build a local version from the [source|https://github.com/bakhirev/assayo].
|
||||||
|
§ page.common.words.title: Word Statistics.
|
||||||
|
§ page.common.words.description: the most popular word. Occurs $1 times.
|
||||||
|
§ page.common.commits.title: Number of commits by days.
|
||||||
|
§ page.common.commits.description: ($1) the most productive day in terms of the number of commits.
|
||||||
|
§ page.common.commits.title2: $1 commits made: $2
|
||||||
|
§ page.common.filter.allUsers: Does not matter
|
||||||
|
§ page.print.modal.title: What are we printing?
|
||||||
|
§ page.print.modal.page: Current page
|
||||||
|
§ page.print.modal.type: Current section
|
||||||
|
§ page.print.modal.all: All statistics
|
||||||
|
§ page.print.modal.cancel: Cancel
|
||||||
|
§ page.print.tableOfContents: Table of contents
|
||||||
|
§ page.print.title: Git repository report
|
||||||
|
§ page.print.sub_title: «$1»
|
||||||
|
§ page.print.description: The data for the report was obtained from the commit history.
|
||||||
|
§ page.team.author.title: Employee statistics
|
||||||
|
§ page.team.author.description1: *Part of the statistics* (work speed, costs, etc.) *for employees with the 'Assistant' type is not counted*, as it is an episodic role in the project. It is assumed that they do not affect the project, and their edits can be disregarded in the context of the overall volume of work.
|
||||||
|
§ page.team.author.description2: *Default sorting* is by the number of tasks and groups (current, fired, assisting employees).
|
||||||
|
§ page.team.author.types: Types of work
|
||||||
|
§ page.team.author.commits: Commits
|
||||||
|
§ page.team.author.commitsSmall: commits
|
||||||
|
§ page.team.author.tasks: Tasks
|
||||||
|
§ page.team.author.tasksSmall: tasks
|
||||||
|
§ page.team.author.workedLosses: Days with and without commits
|
||||||
|
§ page.team.author.worked: work
|
||||||
|
§ page.team.author.losses: days without commits
|
||||||
|
§ page.team.author.days: days
|
||||||
|
§ page.team.author.daysForTask: Days per task
|
||||||
|
§ page.team.author.scopes: Features
|
||||||
|
§ page.team.author.moneyAll: Received
|
||||||
|
§ page.team.author.moneyWorked: Worked for
|
||||||
|
§ page.team.author.moneyLosses: Overpayment
|
||||||
|
§ page.team.hours.title: Distribution of commits during each day of the week
|
||||||
|
§ page.team.month.title: Project work calendar
|
||||||
|
§ page.team.scope.title: Feature statistics
|
||||||
|
§ page.team.scope.scope: Feature
|
||||||
|
§ page.team.scope.days: Working Days
|
||||||
|
§ page.team.scope.authorsDays: Person-Days
|
||||||
|
§ page.team.scope.tasks: Tasks
|
||||||
|
§ page.team.scope.commits: Commits
|
||||||
|
§ page.team.scope.commitsSmall: commits
|
||||||
|
§ page.team.scope.types: Types of work
|
||||||
|
§ page.team.scope.authors: Personal contribution
|
||||||
|
§ page.team.scope.cost: Cost
|
||||||
|
§ page.team.type.title: Task type statistics
|
||||||
|
§ page.team.type.description: *Personal contribution* is counted by the number of commits, not the volume of changed lines or files. Therefore, the "File Analysis" section should also be consulted to assess the scale of changes.
|
||||||
|
§ page.team.type.type: Type of work
|
||||||
|
§ page.team.type.tasks: Tasks
|
||||||
|
§ page.team.type.tasksSmall: tasks
|
||||||
|
§ page.team.type.days: Days
|
||||||
|
§ page.team.type.daysSmall: days
|
||||||
|
§ page.team.type.authorsDays: Person-days
|
||||||
|
§ page.team.type.commits: Commits
|
||||||
|
§ page.team.type.authors: Personal contribution
|
||||||
|
§ page.team.total.titleA: Volume of work
|
||||||
|
§ page.team.total.titleB: Cost
|
||||||
|
§ page.team.total.daysWorked.title: person-days
|
||||||
|
§ page.team.total.daysWorked.description: Only days with commits are counted
|
||||||
|
§ page.team.total.commits.title: commits
|
||||||
|
§ page.team.total.commits.description: Deleted branches are not counted
|
||||||
|
§ page.team.total.daysLosses.title: days without commits
|
||||||
|
§ page.team.total.daysLosses.description: All days minus: holidays, weekends, vacation, days with commits
|
||||||
|
§ page.team.total.employment.title: working / dismissed
|
||||||
|
§ page.team.total.employment.description: If an employee does not make any commits within a month, they are considered dismissed
|
||||||
|
§ page.team.total.moneyAll.title: total
|
||||||
|
§ page.team.total.moneyAll.description: Total salary expenses
|
||||||
|
§ page.team.total.moneyWorked.title: actual
|
||||||
|
§ page.team.total.moneyWorked.description: Actual days worked multiplied by average salary
|
||||||
|
§ page.team.total.moneyLosses.title: possible overpayment
|
||||||
|
§ page.team.total.moneyLosses.description: Paid working days when there were no commits
|
||||||
|
§ page.team.total.weekendPayment.title: weekend work
|
||||||
|
§ page.team.total.weekendPayment.description: Total overpayment for weekend work
|
||||||
|
§ page.team.total.workSpeed.title: tasks per day
|
||||||
|
§ page.team.total.workSpeed.description: Average work speed of the team with the current composition of employees
|
||||||
|
§ page.team.total.moneySpeed.title: per month
|
||||||
|
§ page.team.total.moneySpeed.description: Forecasted salary payment amount with the current team composition, excluding taxes and related expenses
|
||||||
|
§ page.team.total.description1: *Person-days* — the work of one employee during a single working day. For example, in one calendar day, a team of three employees produces a work volume of three person-days.
|
||||||
|
§ page.team.total.description2: *Absentee days* are counted only as working days when commits could have been made. Weekends, public holidays, and vacations are not included in the calculation.
|
||||||
|
§ page.team.total.description3: The *working and dismissed* card shows the actual composition of employees who are continuously involved in work. Additionally, there are "assistants" — typically employees of a different specialization who may occasionally make commits to the project.
|
||||||
|
§ page.team.total.description4: *Overpayment* includes only working days when commits could have been made. Weekends, public holidays, and vacations are not included in the calculation. This is why overpayment + actual cost != total. The total cost includes payment for weekends, public holidays, and vacations.
|
||||||
|
§ page.team.total.description5: *Weekend work* is calculated at a rate of x2 the payment of a regular day. The displayed amount is specifically the overpayment (x1), as the fact of overtime in this context is not of interest. We focus on overpayment when increasing work speed.
|
||||||
|
§ page.team.tree.title: Project Tree Considering Selected Filters
|
||||||
|
§ page.team.tree.filters.author: Employee
|
||||||
|
§ page.team.tree.filters.commits: Number of commits
|
||||||
|
§ page.team.tree.filters.help: The minimum number of commits an employee has made in a file
|
||||||
|
§ page.team.tree.filters.all: All employees
|
||||||
|
§ page.team.tree.add: Who added
|
||||||
|
§ page.team.tree.change: Who changed
|
||||||
|
§ page.team.tree.remove: Who removed
|
||||||
|
§ page.team.tree.line: lines
|
||||||
|
§ page.team.tree.lineAdd: added
|
||||||
|
§ page.team.tree.lineRemove: changed
|
||||||
|
§ page.team.week.title: Weekly statistics
|
||||||
|
§ page.team.week.date: Date
|
||||||
|
§ page.team.week.numberTasks: Number of tasks
|
||||||
|
§ page.team.week.people: Number of people
|
||||||
|
§ page.team.week.line: Line Changes
|
||||||
|
§ page.team.week.days: Days with and without commits
|
||||||
|
§ page.team.week.lossesDetails: Who did not commit
|
||||||
|
§ page.team.week.add: added
|
||||||
|
§ page.team.week.change: changed
|
||||||
|
§ page.team.week.remove: removed
|
||||||
|
§ page.team.week.hasCommits: had commits
|
||||||
|
§ page.team.week.hasNotCommits: had no commits
|
||||||
|
§ page.team.week.days: days
|
||||||
|
§ page.team.week.tasks: tasks
|
||||||
|
§ page.team.pr.task: Task
|
||||||
|
§ page.team.pr.tasks: tasks
|
||||||
|
§ page.team.pr.firstCommitTime: First commit
|
||||||
|
§ page.team.pr.lastCommitTime: Last
|
||||||
|
§ page.team.pr.workDays: Development days
|
||||||
|
§ page.team.pr.delayDays: Days waiting for merge
|
||||||
|
§ page.team.pr.commits: Commits
|
||||||
|
§ page.team.pr.date: Merge Date
|
||||||
|
§ page.team.pr.mergeAuthor: Merged by
|
||||||
|
§ page.team.pr.author: Employee
|
||||||
|
§ page.team.pr.middleTimeRelease: Average delivery time (days)
|
||||||
|
§ page.team.pr.work: development
|
||||||
|
§ page.team.pr.delay: waiting
|
||||||
|
§ page.team.pr.days: days
|
||||||
|
§ page.team.pr.oneTaskDays: Time spent on one task
|
||||||
|
§ page.team.pr.description1: *Development time* is the time difference from the first to the last commit on a task. It does not matter if there were breaks of several days between commits or not. Any commit increases the time.
|
||||||
|
§ page.team.pr.description2: *Waiting time* is the time between the last commit and the code merge. It shows the actual downtime while waiting for something.
|
||||||
|
§ page.team.pr.description3: *Why display development time* without splitting into coding and code review? To show the business the actual delivery time of the code. Waiting for testing, review comments, DevOps problems, and other process imperfections are already included in this term.
|
||||||
|
§ page.team.pr.statByAuthors: Statistics by employees
|
||||||
|
§ page.team.pr.longDelay: Prolonged Waiting for merge
|
||||||
|
§ page.team.tasks.task: Task
|
||||||
|
§ page.team.tasks.author: First commit author
|
||||||
|
§ page.team.tasks.from: First commit
|
||||||
|
§ page.team.tasks.to: Last commit
|
||||||
|
§ page.team.tasks.daysInWork: Days in work
|
||||||
|
§ page.team.tasks.commits: Commits number
|
||||||
|
§ page.team.tasks.pr: Merge date
|
||||||
|
§ page.team.tasks.prAuthor: Merged by user
|
||||||
|
§ page.team.tasks.prDelayDays: Delay before merge in days
|
||||||
|
§ page.team.tasks.comments: Comments
|
||||||
|
§ page.person.print.photo.title: Photo
|
||||||
|
§ page.person.print.photo.description: space for a photo
|
||||||
|
§ page.person.total.title: Main characteristics
|
||||||
|
§ page.person.total.daysWorked.title: days of work
|
||||||
|
§ page.person.total.daysWorked.description: Only days with commits are counted
|
||||||
|
§ page.person.total.tasks.title: tasks
|
||||||
|
§ page.person.total.tasks.description: If commits are properly signed
|
||||||
|
§ page.person.character.title: Character
|
||||||
|
§ page.person.achievement.title: Achievements
|
||||||
|
§ page.person.achievement.positive: Positive
|
||||||
|
§ page.person.achievement.normal: Neutral
|
||||||
|
§ page.person.achievement.negative: Negative
|
||||||
|
§ page.person.achievement.description: The more negative achievements an employee accumulates, the higher the likelihood that the situation is unusual. It may be necessary to change their work mode, tasks, or reporting. A discussion with them to understand what problems are hindering their work is advisable.
|
||||||
|
§ page.person.gets.title: Gets taken:
|
||||||
|
§ page.person.gets.description: "Taking a get" in this context means being the first to leave a commit on a task with a "nice" number.
|
||||||
|
§ page.person.business.days.title: days of work
|
||||||
|
§ page.person.business.days.description: Only days with commits are counted
|
||||||
|
§ page.person.business.tasks.title: tasks
|
||||||
|
§ page.person.business.tasks.description: If commits are properly signed
|
||||||
|
§ page.person.business.losses.title: days without commits
|
||||||
|
§ page.person.business.losses.description: All days minus: holidays, weekends, vacation, days with commits
|
||||||
|
§ page.person.business.commits.title: commits
|
||||||
|
§ page.person.business.commits.description: Deleted branches are not counted
|
||||||
|
§ page.person.business.time.description: Time from the first to the last commit (including non-working days)
|
||||||
|
§ page.person.business.time.title: Days on the project:
|
||||||
|
§ page.person.business.time.dismissed: (dismissed)
|
||||||
|
§ page.person.business.time.staff: (not in the team)
|
||||||
|
§ page.person.business.achievements: Achievements
|
||||||
|
§ page.person.changes.title: Achievements
|
||||||
|
§ page.person.changes.description:
|
||||||
|
With some types of formatting, git marks lines as "deleted" and "added",
|
||||||
|
although in reality, they were "changed". Therefore, if you conducted a major refactoring,
|
||||||
|
git might show a small number of changes in the statistics, but the actual result
|
||||||
|
will be marked as a jump in "deleted" and "added" lines.
|
||||||
|
§ page.person.changes.description: List of commits and the number of changes in them for that day:
|
||||||
|
§ page.person.commits.title: List of commits:
|
||||||
|
§ page.person.money.title.total: Total over time
|
||||||
|
§ page.person.money.title.middle: Average cost
|
||||||
|
§ page.person.money.moneyAll.title: received
|
||||||
|
§ page.person.money.moneyAll.description: Assumed total salary from the project (see settings)
|
||||||
|
§ page.person.money.moneyWorked.title: worked for
|
||||||
|
§ page.person.money.moneyWorked.description: Actual days worked multiplied by average salary
|
||||||
|
§ page.person.money.moneyLosses.title: possible overpayment
|
||||||
|
§ page.person.money.moneyLosses.description: Days without commits multiplied by average salary
|
||||||
|
§ page.person.money.tasks.title: task
|
||||||
|
§ page.person.money.tasks.description: Number of closed tasks to the cost of the day
|
||||||
|
§ page.person.money.commits.title: commit
|
||||||
|
§ page.person.money.commits.description: Number of commits to the cost of the workday
|
||||||
|
§ page.person.speed.task: One task on average is
|
||||||
|
§ page.person.speed.max: Maximum speed per day
|
||||||
|
§ page.person.speed.days.title: days
|
||||||
|
§ page.person.speed.days.description: Refers to workdays, if commits are properly signed
|
||||||
|
§ page.person.speed.commits.title: commits
|
||||||
|
§ page.person.speed.commits.description: Top and bottom 10% of values are trimmed
|
||||||
|
§ page.person.speed.line.title: lines of code
|
||||||
|
§ page.person.speed.line.description: Top and bottom 10% of values are trimmed
|
||||||
|
§ page.person.speed.tasks.title: tasks
|
||||||
|
§ page.person.speed.tasks.description: A task may not be completed, but work should be done on it
|
||||||
|
§ page.person.speed.maxCommits.title: commits
|
||||||
|
§ page.person.speed.maxCommits.description: A task may not be completed, but work should be done on it
|
||||||
|
§ page.person.hours.title: Distribution of commits during each day of the week
|
||||||
|
§ page.person.week.date: Date
|
||||||
|
§ page.person.week.tasks: Number of tasks
|
||||||
|
§ page.person.week.workDays: Days with commits
|
||||||
|
§ page.person.week.taskInDay: Tasks per day
|
||||||
|
§ page.person.week.days: days
|
||||||
|
§ page.person.week.workDay: weekdays
|
||||||
|
§ page.person.week.weekends: weekends
|
||||||
|
`;
|
504
src/ts/translations/de/recommendations.ts
Normal file
504
src/ts/translations/de/recommendations.ts
Normal file
|
@ -0,0 +1,504 @@
|
||||||
|
export default `
|
||||||
|
§ recommendations.modal.cancel: Ok
|
||||||
|
§ recommendations.title
|
||||||
|
Recommendations and Facts
|
||||||
|
|
||||||
|
§ recommendations.timestamp.firstCommit.description
|
||||||
|
made the first commit
|
||||||
|
|
||||||
|
Day of the Week: $1
|
||||||
|
|
||||||
|
§ recommendations.timestamp.lastCommit.description
|
||||||
|
made the last commit
|
||||||
|
|
||||||
|
Day of the Week: $1
|
||||||
|
|
||||||
|
§ recommendations.timestamp.common.title: $1 days
|
||||||
|
§ recommendations.timestamp.allDays.description: from the first to the last commit (including weekends and holidays).
|
||||||
|
§ recommendations.timestamp.lossesDays.description: days without commits, even considering weekends, vacation, and public holidays.
|
||||||
|
§ recommendations.timestamp.weekendDays.description
|
||||||
|
working on weekends
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- employees burn out faster;
|
||||||
|
|
||||||
|
§ recommendations.timestamp.regularWeekendWord.title: Regular Overtime
|
||||||
|
§ recommendations.timestamp.sometimeWeekendWord.title: Occasional Overtime
|
||||||
|
§ recommendations.timestamp.weekendWord.description
|
||||||
|
It might be advisable to change the project manager, analyst, and architect.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- the quality of the product is usually low;
|
||||||
|
- some employees resign;
|
||||||
|
- new errors emerge due to the rush;
|
||||||
|
|
||||||
|
# Most likely:
|
||||||
|
- deadlines were incorrectly estimated at the beginning;
|
||||||
|
- technical specifications are missing;
|
||||||
|
- weak analytics;
|
||||||
|
- weak architecture (no architect was hired, and the team consists of mid-level developers);
|
||||||
|
- started writing code first, then planning;
|
||||||
|
- lack of proper processes to understand mistakes;
|
||||||
|
|
||||||
|
§ recommendations.timestamp.neverWeekendWord.title: Usually Without Overtime
|
||||||
|
§ recommendations.timestamp.neverWeekendWord.description
|
||||||
|
But sometimes it happens.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- employees burn out faster;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.not.title
|
||||||
|
No Parallel Work
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.not.description
|
||||||
|
any feature at any given time is done by one person.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is less than 1.3, we consider that there is usually no parallel work within most features;
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- increases bus factor;
|
||||||
|
- employees develop more slowly;
|
||||||
|
- difficult to properly check an employee's work;
|
||||||
|
|
||||||
|
# Why this is good:
|
||||||
|
- experts emerge who are deeply immersed in the subject area and can offer more quality solutions;
|
||||||
|
- most likely there are no merge conflicts;
|
||||||
|
- the project can quickly develop in different directions simultaneously;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.has.title
|
||||||
|
Some Work Done in Parallel
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.has.description
|
||||||
|
Sometimes a feature is worked on simultaneously by several people.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is from 1.3 to 2.0, we consider that some of the work within different features is sometimes done in parallel;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.every.title
|
||||||
|
Parallel Work
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.every.description
|
||||||
|
any feature at any given time is worked on by several people
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is more than two, we consider that most of the work within different features is usually done in parallel;
|
||||||
|
|
||||||
|
§ recommendations.scope.money
|
||||||
|
this is the estimated cost for the work on this project.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days spent on development are multiplied by the individual salaries of the developers;
|
||||||
|
|
||||||
|
To change the salary of each developer for a more accurate total, go to the "Settings" section.
|
||||||
|
|
||||||
|
# Is this too much or too little?
|
||||||
|
To answer this question, consider the following:
|
||||||
|
- Could a ready-made solution have been purchased for this amount of money?
|
||||||
|
- Could a better product have been developed for this amount of money?
|
||||||
|
|
||||||
|
If the answer to both questions is "yes," then perhaps developing from scratch was not worth the money spent.
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.everyHasOne.title
|
||||||
|
Bus factor = 1
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.everyHasOne.description
|
||||||
|
Most features are deeply understood by only one person.
|
||||||
|
It's necessary to rotate people.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- if employees resign, it will be difficult to continue their work;
|
||||||
|
- it’s impossible to control the quality of their code;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- more than 80% of commits in a feature are made by one person;
|
||||||
|
- the project has more than 60% of such features;
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.oneMaintainer
|
||||||
|
one person is deeply involved in a feature.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- if they resign, it will be hard to continue development;
|
||||||
|
- the quality of code-review decreases;
|
||||||
|
- it’s difficult to parallelize development when needed;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- more than 80% of commits in a feature are made by one person;
|
||||||
|
|
||||||
|
§ recommendations.scope.types.process.title
|
||||||
|
Poor Processes
|
||||||
|
|
||||||
|
§ recommendations.scope.types.process.description
|
||||||
|
Most features contain one type of task.
|
||||||
|
|
||||||
|
§ recommendations.scope.types.one
|
||||||
|
features contain one type of task.
|
||||||
|
|
||||||
|
§ recommendations.scope.types.common
|
||||||
|
It's possible that developers are incorrectly signing commits or the manager is entering the same type of tasks.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- it's impossible to hand over support to another team;
|
||||||
|
- it's impossible to release a "boxed" version;
|
||||||
|
- strong dependence on specific developers;
|
||||||
|
- a high number of errors and low code quality;
|
||||||
|
- potential slowdown in development in the future;
|
||||||
|
|
||||||
|
# The manager's mistake:
|
||||||
|
- viewing the product only from the perspective of a "working demo";
|
||||||
|
|
||||||
|
# What should be done:
|
||||||
|
- tests;
|
||||||
|
- bugs (identified through testing);
|
||||||
|
- refactoring (as architecture may change);
|
||||||
|
- documentation;
|
||||||
|
- style revisions (as a result of focus group feedback);
|
||||||
|
|
||||||
|
§ recommendations.scope.plan.title
|
||||||
|
Develop a Long-Term Plan
|
||||||
|
|
||||||
|
§ recommendations.scope.plan.description
|
||||||
|
taking architecture into account.
|
||||||
|
|
||||||
|
This plan should immediately focus on the most challenging tasks.
|
||||||
|
|
||||||
|
# Why the lack of a plan is bad:
|
||||||
|
- employees create a minimally viable version without planning for expansion points. After this, unscalable code is written, which slows down future features;
|
||||||
|
|
||||||
|
# The manager's mistake:
|
||||||
|
- they haven't shown how the product will develop further and where the growth points will be;
|
||||||
|
|
||||||
|
# How it should be done:
|
||||||
|
- a global product development plan is created;
|
||||||
|
- a global architecture development plan is created (with developers and DBAs);
|
||||||
|
- potential significant changes are discussed upfront at the schematic level;
|
||||||
|
|
||||||
|
§ recommendations.scope.cost.title
|
||||||
|
Evaluate Investment in a Feature
|
||||||
|
|
||||||
|
§ recommendations.scope.cost.description
|
||||||
|
in terms of potential profit.
|
||||||
|
|
||||||
|
Features that are expensive to develop but bring little profit may need to be postponed or even canceled. This will make the project more commercially successful.
|
||||||
|
|
||||||
|
§ recommendations.author.lotOfLazy
|
||||||
|
writes too little code.
|
||||||
|
|
||||||
|
# Should they be fired?
|
||||||
|
- are they a team leader, architect, or analyst?
|
||||||
|
- is this their primary project?
|
||||||
|
- are there any dependencies on them?
|
||||||
|
|
||||||
|
# Why it makes no sense to correct
|
||||||
|
The total costs for the developer are already more than the profit from their work.
|
||||||
|
If we believe that there were no objective hindrances to their work, then the person either does not want to work at all or is working on two projects simultaneously.
|
||||||
|
Firing and replacing them with a new employee seems justified from a statistical point of view.
|
||||||
|
|
||||||
|
§ recommendations.author.manyLazy
|
||||||
|
writes little code. Needs to be monitored.
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- in test samples, a good programmer writes code for more than 80% of the time;
|
||||||
|
- in this case, the indicator is between 60% and 80%;
|
||||||
|
|
||||||
|
# How to monitor:
|
||||||
|
- break tasks into 1..2 days;
|
||||||
|
- ask for a status update every day;
|
||||||
|
- ensure tasks are well defined and ready for development;
|
||||||
|
- arrange pair programming to check actual speed;
|
||||||
|
|
||||||
|
§ recommendations.author.oneTypeMans
|
||||||
|
receives too many monotonous tasks of the same type. Risk of burnout.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- if an employee burns out, their work speed will decrease;
|
||||||
|
- professional growth slows down;
|
||||||
|
- the likelihood of resignation increases;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- the type of task is determined for each commit;
|
||||||
|
- if more than 70% of tasks are of the same type, it means the person is doing the same thing repeatedly;
|
||||||
|
|
||||||
|
§ recommendations.author.workToday.title: Working $1
|
||||||
|
§ recommendations.author.workToday.description
|
||||||
|
on the project at this moment.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- more than 50% of workdays;
|
||||||
|
- have worked during the last 30 days;
|
||||||
|
|
||||||
|
§ recommendations.author.dismissed.title: Dismissed $1
|
||||||
|
§ recommendations.author.dismissed.description
|
||||||
|
or worked for a short period.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- worked at a normal pace (apparently, this is their main repository);
|
||||||
|
- no commits in the last month;
|
||||||
|
- vacation usually lasts 14 days (their absence does not resemble a vacation);
|
||||||
|
|
||||||
|
§ recommendations.author.staff.title: Assisting $1
|
||||||
|
§ recommendations.author.staff.description
|
||||||
|
People of other specializations who have committed something.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- this is not an open-source project;
|
||||||
|
- workdays less than 15% of the total number;
|
||||||
|
- modify roughly the same files;
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.openSource.title
|
||||||
|
Open Project
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.openSource.description
|
||||||
|
they do not work five days a week here.
|
||||||
|
|
||||||
|
The project may be closed, but this work pace is typical for open libraries on GitHub.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- statistics are taken for all active developers;
|
||||||
|
- the average number of working days and days without commits is calculated;
|
||||||
|
- for open-source libraries, working days are usually a maximum of 15..20%;
|
||||||
|
|
||||||
|
# Consequences
|
||||||
|
For projects where work is not constant, many indicators do not make sense. Therefore, indicators like days without commits, speed, etc., will be hidden.
|
||||||
|
|
||||||
|
Typically, such projects are assessed before starting the development of their own closed version. The most interesting indicators in this case are the probable cost and total development time.
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.easy.title
|
||||||
|
Light Workload
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.easy.description
|
||||||
|
too many days without commits. It is necessary to understand why the team is not writing code.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- take statistics from all active developers;
|
||||||
|
- calculate the average number of working days and days without commits;
|
||||||
|
- workload is considered light if the percentage of days without commits is between 5% and 20%;
|
||||||
|
|
||||||
|
# Possible reasons:
|
||||||
|
- there are actually no tasks;
|
||||||
|
- there are tasks, but they fit well with the current architecture;
|
||||||
|
- developers are distracted by meetings;
|
||||||
|
- the team is not working;
|
||||||
|
|
||||||
|
# Solutions:
|
||||||
|
- discuss the issue with the team;
|
||||||
|
- reduce task granularity so that one or two tasks can be completed in a day;
|
||||||
|
- introduce daily meetings to check the status of tasks;
|
||||||
|
- arrange pair programming sessions to ensure that the developer can work faster;
|
||||||
|
|
||||||
|
§ recommendations.author.manager.title
|
||||||
|
Set Deadlines
|
||||||
|
|
||||||
|
§ recommendations.author.manager.description
|
||||||
|
Every task should have a clear deadline.
|
||||||
|
|
||||||
|
This will prevent dragging out its completion for several days or weeks.
|
||||||
|
|
||||||
|
# Indicators to check:
|
||||||
|
- the number of days spent on one task by an employee;
|
||||||
|
- the number of days waiting for PR merge (PR statistics page);
|
||||||
|
|
||||||
|
§ recommendations.author.shorTalk.title
|
||||||
|
Conduct Daily Meetings
|
||||||
|
|
||||||
|
§ recommendations.author.shorTalk.description
|
||||||
|
they help stay informed about the project.
|
||||||
|
|
||||||
|
Do not stretch them by getting sidetracked on irrelevant topics.
|
||||||
|
|
||||||
|
# Questions the employee should answer:
|
||||||
|
- what was done;
|
||||||
|
- what will be done;
|
||||||
|
- are there any issues;
|
||||||
|
|
||||||
|
# Interruptions should occur if:
|
||||||
|
- they start describing minor details in-depth, which are not important;
|
||||||
|
- they steer the conversation away from the original plan;
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
Often an employee who does nothing tries to avoid the answer by telling a bunch of unnecessary details of their work. This lulls the participants' attention and stretches the time for a response. It creates an impression that they are busy, even though there was no actual work done.
|
||||||
|
|
||||||
|
§ recommendations.author.ipr.title
|
||||||
|
Develop a Training Plan
|
||||||
|
|
||||||
|
§ recommendations.author.ipr.description
|
||||||
|
for each employee.
|
||||||
|
|
||||||
|
*Individual training plan* is a list of goals and tasks that help a person develop in a certain area.
|
||||||
|
|
||||||
|
# How to create a plan:
|
||||||
|
- create a competency matrix;
|
||||||
|
- identify which competencies have the least knowledge and experience;
|
||||||
|
- find out which of these competencies are of interest to the employee;
|
||||||
|
- come up with 3..5 goals within each such competency for the next six months or a year;
|
||||||
|
- try to do something every month to achieve one goal;
|
||||||
|
- remind every month about the overall plan to achieve these goals;
|
||||||
|
|
||||||
|
# Does a manager need a plan?
|
||||||
|
Yes, the manager should also make a plan for themselves. If there is no higher-level manager, they should self-assess.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- employees become more loyal to the company;
|
||||||
|
- you get more qualified personnel for the same money;
|
||||||
|
|
||||||
|
§ recommendations.author.oneToOne.title
|
||||||
|
Conduct One-on-One Meetings Every Month
|
||||||
|
|
||||||
|
§ recommendations.author.oneToOne.description
|
||||||
|
it helps to identify problems at an early stage.
|
||||||
|
|
||||||
|
*One-to-one* is a regular personal meeting of a manager with a subordinate. Such meetings typically discuss everything important to the employee, what concerns them, and what they can share with the manager in private.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- easy to find out who is overburdened and who has free time;
|
||||||
|
- possible to prevent employee burnout;
|
||||||
|
- quick feedback can be obtained about processes that you might not notice;
|
||||||
|
- trust is built, making employees more loyal to the company;
|
||||||
|
- increases employee motivation and engagement;
|
||||||
|
|
||||||
|
§ recommendations.author.club.title
|
||||||
|
Go to a Bar
|
||||||
|
|
||||||
|
§ recommendations.author.club.description
|
||||||
|
once a month or two.
|
||||||
|
|
||||||
|
This will help build informal communication within the team and bring the team together, even if the interaction is brief.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- quick feedback can be obtained about processes that you might not notice;
|
||||||
|
- trust is built, making employees more loyal to the company;
|
||||||
|
- increases employee engagement;
|
||||||
|
|
||||||
|
§ recommendations.hour.onlyWork.title: No Weekends Here
|
||||||
|
§ recommendations.hour.onlyWork.description: The project manager should probably be fired.
|
||||||
|
§ recommendations.hour.weekends.title: Working on Weekends
|
||||||
|
§ recommendations.hour.weekends.description: The project manager should probably be checked.
|
||||||
|
§ recommendations.hour.easy.title: There Are Problems
|
||||||
|
§ recommendations.hour.easy.description: There are likely crunch times and work is needed on weekends.
|
||||||
|
§ recommendations.week.lazyDays.down.title: Fewer Absences
|
||||||
|
§ recommendations.week.lazyDays.down.description: this indicator has dropped over the last three weeks
|
||||||
|
§ recommendations.week.lazyDays.up.title: More Absences
|
||||||
|
§ recommendations.week.lazyDays.up.description: no tasks or stricter control is needed
|
||||||
|
§ recommendations.week.notWork.title: Consistently Underperforms
|
||||||
|
§ recommendations.week.notWork.description: as every week the code is not 100% of the time
|
||||||
|
§ recommendations.week.upWork.title: Consistently Overworks
|
||||||
|
§ recommendations.week.upWork.description: as every week code is written on weekend days
|
||||||
|
§ recommendations.week.task.up.title: Productivity is growing
|
||||||
|
§ recommendations.week.task.up.description: or tasks have become too small. Need to check. If granularity is the same - reinforce the result.
|
||||||
|
§ recommendations.week.task.lazyMaintainer.description: consistently leads in absences. Fire?
|
||||||
|
§ recommendations.week.task.down.title: Productivity is Falling
|
||||||
|
§ recommendations.week.task.down.description
|
||||||
|
or tasks are poorly split. Need to check. If granularity is the same - take control.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- the number of tasks per day that are being worked on has been steadily decreasing over the last three weeks.
|
||||||
|
|
||||||
|
# Possible errors:
|
||||||
|
- tasks could have been more complex than they seemed;
|
||||||
|
- tasks could have had a large volume of work (need to check if the number of changes is also decreasing during this period)
|
||||||
|
|
||||||
|
§ recommendations.type.everyHasOne.title: Not Signing Task Types
|
||||||
|
§ recommendations.type.everyHasOne.description: Most task types are done by one person.
|
||||||
|
§ recommendations.type.oneMaintainer.title: Narrow Specialization
|
||||||
|
§ recommendations.type.oneMaintainer.description
|
||||||
|
most tasks of one type are done by the same people.
|
||||||
|
|
||||||
|
# Task types:
|
||||||
|
|
||||||
|
§ recommendations.type.common
|
||||||
|
# It might not be the case
|
||||||
|
|
||||||
|
Make sure that other employees correctly sign commits.
|
||||||
|
|
||||||
|
Steps to ensure this:
|
||||||
|
- set up a pre-commit check for commit messages;
|
||||||
|
- explain to the team the need to indicate the type;
|
||||||
|
- check in new branches that employees follow this rule;
|
||||||
|
|
||||||
|
# If it is indeed the case
|
||||||
|
|
||||||
|
You have set up checks and ensured that the same employee does tasks of the same type.
|
||||||
|
|
||||||
|
Why this is bad:
|
||||||
|
- their resignation will halt a whole bunch of processes;
|
||||||
|
- it reduces the competence of other team members;
|
||||||
|
- difficult to understand their edits at a higher level;
|
||||||
|
|
||||||
|
How to fix this:
|
||||||
|
- distribute different types of tasks evenly;
|
||||||
|
- change the area of work (tests, documentation, bugs) among employees every sprint;
|
||||||
|
|
||||||
|
§ recommendations.type.fewTypes.title
|
||||||
|
This is a Local Product
|
||||||
|
|
||||||
|
§ recommendations.type.fewTypes.description
|
||||||
|
for a specific customer or problem.
|
||||||
|
|
||||||
|
# Signs of a "global" product:
|
||||||
|
- localization;
|
||||||
|
- documentation;
|
||||||
|
- a large volume of tests;
|
||||||
|
- visual customization;
|
||||||
|
- refactoring of bottlenecks;
|
||||||
|
- etc.
|
||||||
|
|
||||||
|
# Why this product looks like a "local" one:
|
||||||
|
- each "global" sign will be outweighed by its type of task;
|
||||||
|
- the more "global" signs, the more likely a "global" product;
|
||||||
|
|
||||||
|
In this case, we see a small number of types, which likely indicates shortcomings that prevent the product from being easily scaled to the global market and sold in other countries.
|
||||||
|
|
||||||
|
# It might not be the case
|
||||||
|
Based on file types, we can assume the type of program (website, server application, DevOps scripts, etc.). For a frontend application, our hypothesis will be more accurate than for DevOps scripts, which might just be a micro-module of initialization.
|
||||||
|
|
||||||
|
§ recommendations.type.diff.title
|
||||||
|
Break Down the Leading Type into Subtypes
|
||||||
|
|
||||||
|
§ recommendations.type.diff.description
|
||||||
|
to detail errors.
|
||||||
|
|
||||||
|
Typically, the task type labeled "bug fixing" is leading. This makes the statistics weakly detailed.
|
||||||
|
|
||||||
|
*If you encounter this situation*, you can break down this type into subtypes (e.g., based on the location of detection).
|
||||||
|
|
||||||
|
Consider several options for subtypes:
|
||||||
|
- fix_dev (error detected during development);
|
||||||
|
- fix_test (error detected during testing);
|
||||||
|
- fix (error detected in production);
|
||||||
|
|
||||||
|
§ recommendations.type.buddy.title
|
||||||
|
Accumulate Minor Tasks
|
||||||
|
|
||||||
|
§ recommendations.type.buddy.description
|
||||||
|
for new employees.
|
||||||
|
|
||||||
|
# If a task is:
|
||||||
|
- not important;
|
||||||
|
- not big;
|
||||||
|
- doesn't require deep immersion in the context;
|
||||||
|
- more about refactoring than new code;
|
||||||
|
|
||||||
|
# Put it in the backlog with the label "for beginners".
|
||||||
|
|
||||||
|
When a new employee arrives, you will be able to immediately pull out a bunch of small and varied tasks for them to get acquainted with the project.
|
||||||
|
|
||||||
|
Also, if you have a lull in work, you can pull out one such minor task from the backlog.
|
||||||
|
`;
|
27
src/ts/translations/de/settings.ts
Normal file
27
src/ts/translations/de/settings.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ page.settings.document.title: Display settings
|
||||||
|
§ page.settings.document.name: Page title
|
||||||
|
§ page.settings.document.language: Interface language
|
||||||
|
§ page.settings.links.title: Link prefixes
|
||||||
|
§ page.settings.links.task: For task numbers
|
||||||
|
§ page.settings.links.pr: For PR
|
||||||
|
§ page.settings.user.title: Individual settings
|
||||||
|
§ page.settings.user.notFound: No individual settings. Data for all employees are calculated based on common parameters.
|
||||||
|
§ page.settings.user.subTitle: Addendum to employment contract №$1
|
||||||
|
§ page.settings.user.from: Start date
|
||||||
|
§ page.settings.mailmap: .mailmap example
|
||||||
|
§ page.settings.common.title: General salary data
|
||||||
|
§ page.settings.common.type.title: Project work type
|
||||||
|
§ page.settings.common.type.full: Full-time employment
|
||||||
|
§ page.settings.common.type.part: Project work
|
||||||
|
§ page.settings.common.salary: Monthly salary
|
||||||
|
§ page.settings.common.currency: Currency
|
||||||
|
§ page.settings.common.workDaysInYear: Number of working days in a year
|
||||||
|
§ page.settings.common.vacationDaysInYear: Number of vacation days in a year
|
||||||
|
§ page.settings.common.workDaysInWeek: Workdays
|
||||||
|
§ page.settings.form.save: Save
|
||||||
|
§ page.settings.form.cancel: Cancel
|
||||||
|
§ page.settings.form.remove: Remove
|
||||||
|
§ page.settings.form.addEmployee: Add an employee
|
||||||
|
§ page.settings.form.addContract: Add an employment contract
|
||||||
|
`;
|
27
src/ts/translations/es/Spenish_common.ts
Normal file
27
src/ts/translations/es/Spenish_common.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ uiKit.console.button: Copiar
|
||||||
|
§ uiKit.console.notification: Texto copiado
|
||||||
|
§ uiKit.dataLoader.page: Página
|
||||||
|
§ uiKit.dataLoader.size: Se muestra por
|
||||||
|
§ uiKit.dataLoader.from: de
|
||||||
|
§ uiKit.dataLoader.all: Mostrar todo
|
||||||
|
§ uiKit.hoursChart.work: tiempo de trabajo estándar (lunes a viernes, de 07:00 a 20:00)
|
||||||
|
§ uiKit.hoursChart.weekend: Días de descanso o tiempo antes/después del día de trabajo
|
||||||
|
§ uiKit.hoursChart.days: Número total de commits en todo momento en un día y una hora específicos
|
||||||
|
§ uiKit.page.remove: Eliminar
|
||||||
|
§ uiKit.nothingFound.common.title: No hay o no hay suficientes datos para mostrar.
|
||||||
|
§ uiKit.nothingFound.common.description: El sistema procesará más datos si los commits están firmados en formato [Git commit message convention|https://www.conventionalcommits.org/en/v1.0.0/]. Plantilla:
|
||||||
|
§ uiKit.nothingFound.common.console: Nombre_tipo de tarea(módulos): explicación
|
||||||
|
§ uiKit.nothingFound.common.example: Por ejemplo:
|
||||||
|
§ uiKit.nothingFound.staff.title: No hay datos para este empleado
|
||||||
|
§ uiKit.nothingFound.staff.description1:
|
||||||
|
Hacía cambios no todos los días laborables. Por lo tanto, recibió el estatus “Ayudante”.
|
||||||
|
La estadística del empleado con este estatus puede no ser tenida en cuenta. Su impacto es insignificante.
|
||||||
|
§ uiKit.nothingFound.staff.description2:
|
||||||
|
El sistema no calcula para él una serie de indicadores.
|
||||||
|
Si es un error y se necesita tener en cuenta los datos estadísticos de este empleado, vaya a la sección “Configuración” y cambie su tipo.
|
||||||
|
§ common.title: Git estadísticas
|
||||||
|
§ common.filters: Filtros
|
||||||
|
§ common.notifications.save: Cambios guardados
|
||||||
|
§ common.notifications.setting: Ajustes guardados
|
||||||
|
`;
|
|
@ -9,7 +9,6 @@ export default `
|
||||||
§ uiKit.hoursChart.weekend: días o horario antes/después del día laboral
|
§ uiKit.hoursChart.weekend: días o horario antes/después del día laboral
|
||||||
§ uiKit.hoursChart.days: número total de commits en un día y una hora específica
|
§ uiKit.hoursChart.days: número total de commits en un día y una hora específica
|
||||||
§ uiKit.page.remove: Eliminar
|
§ uiKit.page.remove: Eliminar
|
||||||
§ uiKit.races.go: ¡Adelante!
|
|
||||||
§ uiKit.nothingFound.common.title: No hay o no hay suficientes datos para mostrar
|
§ uiKit.nothingFound.common.title: No hay o no hay suficientes datos para mostrar
|
||||||
§ uiKit.nothingFound.common.description: El sistema procesará más datos si los commits se firman con el formato de [Git commit message convention|https://www.conventionalcommits.org/en/v1.0.0/]. Patrón:
|
§ uiKit.nothingFound.common.description: El sistema procesará más datos si los commits se firman con el formato de [Git commit message convention|https://www.conventionalcommits.org/en/v1.0.0/]. Patrón:
|
||||||
§ uiKit.nothingFound.common.console: Número_de_tarea tipo(característica): descripción
|
§ uiKit.nothingFound.common.console: Número_de_tarea tipo(característica): descripción
|
||||||
|
|
|
@ -1,37 +1,40 @@
|
||||||
export default `
|
export default `
|
||||||
§ sidebar.switch.team: Команда
|
§ sidebar.switch.team: Equipo
|
||||||
§ sidebar.switch.person: Сотрудник
|
§ sidebar.switch.person: Empleado
|
||||||
§ sidebar.buttons.settings: Настройки
|
§ sidebar.buttons.settings: Ajustes
|
||||||
§ sidebar.buttons.print: Печать
|
§ sidebar.buttons.print: Impresión
|
||||||
§ sidebar.filters.all: всё время
|
§ sidebar.filters.all: a todas horas
|
||||||
§ sidebar.filters.year: год
|
§ sidebar.filters.year: año
|
||||||
§ sidebar.filters.halfYear: пол года
|
§ sidebar.filters.halfYear: medio año
|
||||||
§ sidebar.filters.month: месяц
|
§ sidebar.filters.month: mes
|
||||||
§ sidebar.filters.week: неделя
|
§ sidebar.filters.week: semana
|
||||||
§ sidebar.team.total: Общая информация
|
§ sidebar.team.total: Información general
|
||||||
§ sidebar.team.scope: Фичи
|
§ sidebar.team.scope: módulos
|
||||||
§ sidebar.team.author: Сотрудники
|
§ sidebar.team.author: Personal
|
||||||
§ sidebar.team.type: Типы задач
|
§ sidebar.team.type: Tipos de tareas
|
||||||
§ sidebar.team.pr: Влитие кода
|
§ sidebar.team.pr: Inyección de código
|
||||||
§ sidebar.team.day: По дням
|
§ sidebar.team.day: Por días
|
||||||
§ sidebar.team.week: По неделям
|
§ sidebar.team.week: Por semana
|
||||||
§ sidebar.team.month: По месяцам
|
§ sidebar.team.month: Por mes
|
||||||
§ sidebar.team.tree: Анализ файлов
|
§ sidebar.team.tree: Análisis de archivos
|
||||||
§ sidebar.team.hours: Расписание
|
§ sidebar.team.files: Ficheros
|
||||||
§ sidebar.team.commits: Все коммиты
|
§ sidebar.team.removedFiles: Archivos eliminados
|
||||||
§ sidebar.team.changes: Все изменения
|
§ sidebar.team.tasks: Lista de tareas
|
||||||
§ sidebar.team.words: Популярные слова
|
§ sidebar.team.hours: Horario
|
||||||
§ sidebar.team.top: Викторина
|
§ sidebar.team.commits: All commits
|
||||||
§ sidebar.team.settings: Настройки
|
§ sidebar.team.changes: Todos los cambios
|
||||||
§ sidebar.person.total: Общая информация
|
§ sidebar.team.words: Palabras populares
|
||||||
§ sidebar.person.money: Стоимость работы
|
§ sidebar.team.top: Concurso
|
||||||
§ sidebar.person.speed: Скорость
|
§ sidebar.team.settings: Ajustes
|
||||||
§ sidebar.person.day: По дням
|
§ sidebar.person.total: Información general
|
||||||
§ sidebar.person.week: По неделям
|
§ sidebar.person.money: Costo del trabajo
|
||||||
§ sidebar.person.month: По месяцам
|
§ sidebar.person.speed: Velocidad
|
||||||
§ sidebar.person.hours: Расписание
|
§ sidebar.person.day: Por días
|
||||||
§ sidebar.person.commits: Все коммиты
|
§ sidebar.person.week: Por semana
|
||||||
§ sidebar.person.changes: Все изменения
|
§ sidebar.person.month: Por mes
|
||||||
§ sidebar.person.words: Популярные слова
|
§ sidebar.person.hours: Horario
|
||||||
§ sidebar.person.settings: Настройки
|
§ sidebar.person.commits: All commits
|
||||||
`;
|
§ sidebar.person.changes: Todos los cambios
|
||||||
|
§ sidebar.person.words: Palabras populares
|
||||||
|
§ sidebar.person.settings: Ajustes
|
||||||
|
`;
|
||||||
|
|
92
src/ts/translations/fr/achievements.ts
Normal file
92
src/ts/translations/fr/achievements.ts
Normal file
|
@ -0,0 +1,92 @@
|
||||||
|
export default `
|
||||||
|
§ achievements.commitsAfter1500.title: Owl
|
||||||
|
§ achievements.commitsAfter1500.description: 70% of commits after 3:00 PM
|
||||||
|
§ achievements.commitsBefore1500.title: Early bird
|
||||||
|
§ achievements.commitsBefore1500.description: 70% of commits before noon
|
||||||
|
§ achievements.workEveryTime.title: Devoted worker
|
||||||
|
§ achievements.workEveryTime.description: a commit for every hour of the day
|
||||||
|
§ achievements.workNotWork.title: Shooting blanks
|
||||||
|
§ achievements.workNotWork.description: commits are there, but no tasks are closed
|
||||||
|
§ achievements.userNotWork.title: Fly-by
|
||||||
|
§ achievements.userNotWork.description: this is not their main project
|
||||||
|
§ achievements.userIsDied.title: Dead soul
|
||||||
|
§ achievements.userIsDied.description: worked, but resigned
|
||||||
|
§ achievements.lessTasks.title: Came and went
|
||||||
|
§ achievements.lessTasks.description: least closed tasks
|
||||||
|
§ achievements.moreTasks.title: Father says well done
|
||||||
|
§ achievements.moreTasks.description: most closed tasks
|
||||||
|
§ achievements.everyMessageLong.title: Master of eloquence
|
||||||
|
§ achievements.everyMessageLong.description: consistently the longest commit messages
|
||||||
|
§ achievements.everyMessageShort.title: Talkative, a spy's dream
|
||||||
|
§ achievements.everyMessageShort.description: consistently, the shortest commit messages
|
||||||
|
§ achievements.shortestName.title: Size doesn't matter
|
||||||
|
§ achievements.shortestName.description: shortest name
|
||||||
|
§ achievements.longestName.title: Azim Aziz Il Am Kadir Imran II
|
||||||
|
§ achievements.longestName.description: longest name
|
||||||
|
§ achievements.moreCommits.title: Backup master
|
||||||
|
§ achievements.moreCommits.description: most commits
|
||||||
|
§ achievements.lessCommits.title: Rare but Precise
|
||||||
|
§ achievements.lessCommits.description: least commits
|
||||||
|
§ achievements.oneCommitOneTask.title: Right on target
|
||||||
|
§ achievements.oneCommitOneTask.description: on average one commit per task
|
||||||
|
§ achievements.moreLazyDays.title: With you in spirit
|
||||||
|
§ achievements.moreLazyDays.description: most days without commits
|
||||||
|
§ achievements.lessLazyDays.title: Papa carlo
|
||||||
|
§ achievements.lessLazyDays.description: least days without commits
|
||||||
|
§ achievements.zeroLazyDays.title: Not a single break
|
||||||
|
§ achievements.zeroLazyDays.description: not a single day without commits
|
||||||
|
§ achievements.moreWorkDays.title: Valuable employee
|
||||||
|
§ achievements.moreWorkDays.description: most working days
|
||||||
|
§ achievements.moreScopes.title: Startuper
|
||||||
|
§ achievements.moreScopes.description: completed the most features
|
||||||
|
§ achievements.lessScopes.title: Dandy
|
||||||
|
§ achievements.lessScopes.description: completed the fewest features
|
||||||
|
§ achievements.moreDaysForTask.title: Snail on the slope
|
||||||
|
§ achievements.moreDaysForTask.description: tasks take longer than others
|
||||||
|
§ achievements.more2DaysForTask.title: Slow and steady
|
||||||
|
§ achievements.more2DaysForTask.description: more than two days per task
|
||||||
|
§ achievements.moreDaysInProject.title: Old-timer
|
||||||
|
§ achievements.moreDaysInProject.description: most days in the project
|
||||||
|
§ achievements.lessDaysInProject.title: And who is this?
|
||||||
|
§ achievements.lessDaysInProject.description: least days in the project
|
||||||
|
§ achievements.more90DaysInProject.title: Welcome aboard
|
||||||
|
§ achievements.more90DaysInProject.description: not fired during the probation period
|
||||||
|
§ achievements.lessDaysForTask.title: Quick draw
|
||||||
|
§ achievements.lessDaysForTask.description: a task takes less than a day
|
||||||
|
§ achievements.adam.title: Adam
|
||||||
|
§ achievements.adam.description: the first stable employee on the project
|
||||||
|
§ achievements.more666DaysInProject.title: Devil
|
||||||
|
§ achievements.more666DaysInProject.description: worked 666 days on the project
|
||||||
|
§ achievements.more777DaysInProject.title: Azino three axes
|
||||||
|
§ achievements.more777DaysInProject.description: worked 777 days on the project
|
||||||
|
§ achievements.moreRefactoring.title: Executive editor
|
||||||
|
§ achievements.moreRefactoring.description: made the most 'refactoring' tags
|
||||||
|
§ achievements.longestMessage.title: So many conversations...
|
||||||
|
§ achievements.longestMessage.description: the longest commit message of all time
|
||||||
|
§ achievements.moreTasksInDay.title: Speed racer
|
||||||
|
§ achievements.moreTasksInDay.description: record for the number of tasks closed in a day
|
||||||
|
§ achievements.hasCommitFrom0to7.title: Night watch
|
||||||
|
§ achievements.hasCommitFrom0to7.description: a commit for every hour of the night
|
||||||
|
§ achievements.noCommitOnDay.title: Technical break
|
||||||
|
§ achievements.noCommitOnDay.description: there is a certain hour and day in working time when never commits
|
||||||
|
§ achievements.hasCommitEveryTime.title: Died at work
|
||||||
|
§ achievements.hasCommitEveryTime.description: a commit for every hour of each day (including weekends)
|
||||||
|
§ achievements.commitsAfter1800.title: Business Time
|
||||||
|
§ achievements.commitsAfter1800.description: no commits after 6:00 PM
|
||||||
|
§ achievements.more1488DaysInProject.title: Named after Maxim Martsinkevich
|
||||||
|
§ achievements.more1488DaysInProject.description: worked 1488 days on the project
|
||||||
|
§ achievements.moreFix.title: Bug hunter
|
||||||
|
§ achievements.moreFix.description: most closed bugs
|
||||||
|
§ achievements.lessWorkDays.title: Count me out
|
||||||
|
§ achievements.lessWorkDays.description: least working days
|
||||||
|
§ achievements.moreCreateCode.title: Creator
|
||||||
|
§ achievements.moreCreateCode.description: tends to add code more than others
|
||||||
|
§ achievements.moreRemoveCode.title: Destroyer
|
||||||
|
§ achievements.moreRemoveCode.description: tends to remove code more than others
|
||||||
|
§ achievements.moreChangeCode.title: Reformer
|
||||||
|
§ achievements.moreChangeCode.description: tends to change code more than others
|
||||||
|
§ achievements.moreStyle.title: Fashion police
|
||||||
|
§ achievements.moreStyle.description: tends to change CSS more than others
|
||||||
|
§ achievements.moreOnHoliday.title: No life
|
||||||
|
§ achievements.moreOnHoliday.description: relatively many commits in non-working hours
|
||||||
|
`;
|
27
src/ts/translations/fr/common.ts
Normal file
27
src/ts/translations/fr/common.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ uiKit.console.button: Copier
|
||||||
|
§ uiKit.console.notification: Texte copié
|
||||||
|
§ uiKit.dataLoader.page: Page
|
||||||
|
§ uiKit.dataLoader.size: Affiché par
|
||||||
|
§ uiKit.dataLoader.from: de
|
||||||
|
§ uiKit.dataLoader.all: Afficher tout
|
||||||
|
§ uiKit.hoursChart.work: temps de travail standard (Les jours ouvrables de 07h00 à 20h00)
|
||||||
|
§ uiKit.hoursChart.weekend: Jours ou heures avant/après les jours ouvrables
|
||||||
|
§ uiKit.hoursChart.days: La somme des commits au cours de tout le temps un certain jour et une certaine heure
|
||||||
|
§ uiKit.page.remove: Supprimer
|
||||||
|
§ uiKit.nothingFound.common.title: Il n’y a pas ou pas assez de données pour afficher.
|
||||||
|
§ uiKit.nothingFound.common.description: Le système traite plus de données si les commits sont signés au format [Git commit message convention|https://www.conventionalcommits.org/en/v1.0.0/]. Modèle:
|
||||||
|
§ uiKit.nothingFound.common.console: Numéro_adresse type(modules): explication
|
||||||
|
§ uiKit.nothingFound.common.example: Par exemple:
|
||||||
|
§ uiKit.nothingFound.staff.title: Il n & apos; y a pas de données sur ce fonctionnaire.
|
||||||
|
§ uiKit.nothingFound.staff.description1:
|
||||||
|
Il a apporté des modifications pas tous les jours ouvrable. Par conséquent, il a reçu le statut «Assistant».
|
||||||
|
La statistique du collaborateur avec ce statut peut ne pas être prise en compte. Son impact est insignifiant.
|
||||||
|
§ uiKit.nothingFound.staff.description2:
|
||||||
|
Le système ne calcule pas pour lui plusieurs indicateurs.
|
||||||
|
Si c’est une erreur et que la statistique pour ce collaborateur doit être prise en compte, accédez à la section “Paramètres” et modifiez son type.
|
||||||
|
§ common.title: Git statistique
|
||||||
|
§ common.filters: Filtres
|
||||||
|
§ common.notifications.save: Modifications enregistrées
|
||||||
|
§ common.notifications.setting: Paramètres enregistrés
|
||||||
|
`;
|
15
src/ts/translations/fr/index.ts
Normal file
15
src/ts/translations/fr/index.ts
Normal file
|
@ -0,0 +1,15 @@
|
||||||
|
import achievements from './achievements';
|
||||||
|
import common from './common';
|
||||||
|
import navigation from './navigation';
|
||||||
|
import recommendations from './recommendations';
|
||||||
|
import settings from './settings';
|
||||||
|
import pages from './pages';
|
||||||
|
|
||||||
|
export default [
|
||||||
|
achievements,
|
||||||
|
common,
|
||||||
|
navigation,
|
||||||
|
recommendations,
|
||||||
|
settings,
|
||||||
|
pages,
|
||||||
|
].join('');
|
40
src/ts/translations/fr/navigation.ts
Normal file
40
src/ts/translations/fr/navigation.ts
Normal file
|
@ -0,0 +1,40 @@
|
||||||
|
export default `
|
||||||
|
§ sidebar.switch.team: Équipe
|
||||||
|
§ sidebar.switch.person: Employé
|
||||||
|
§ sidebar.buttons.settings: Réglages
|
||||||
|
§ sidebar.buttons.print: Impression
|
||||||
|
§ sidebar.filters.all: à toute heure
|
||||||
|
§ sidebar.filters.year: année
|
||||||
|
§ sidebar.filters.halfYear: demi-année
|
||||||
|
§ sidebar.filters.month: mois
|
||||||
|
§ sidebar.filters.week: semaine
|
||||||
|
§ sidebar.team.total: Informations générales
|
||||||
|
§ sidebar.team.scope: modules
|
||||||
|
§ sidebar.team.author: Employés
|
||||||
|
§ sidebar.team.type: Types de tâches
|
||||||
|
§ sidebar.team.pr: injection de code
|
||||||
|
§ sidebar.team.day: Au jour le jour
|
||||||
|
§ sidebar.team.week: Le semaine
|
||||||
|
§ sidebar.team.month: Par mois
|
||||||
|
§ sidebar.team.tree: Analyse des fichiers
|
||||||
|
§ sidebar.team.files: Fichiers
|
||||||
|
§ sidebar.team.removedFiles: Fichiers supprimés
|
||||||
|
§ sidebar.team.tasks: Liste des tâches
|
||||||
|
§ sidebar.team.hours: Horaire
|
||||||
|
§ sidebar.team.commits: all commits
|
||||||
|
§ sidebar.team.changes: Tous les changements
|
||||||
|
§ sidebar.team.words: Mots populaires
|
||||||
|
§ sidebar.team.top: quiz
|
||||||
|
§ sidebar.team.settings: Réglages
|
||||||
|
§ sidebar.person.total: Informations générales
|
||||||
|
§ sidebar.person.money: Coût des travaux
|
||||||
|
§ sidebar.person.speed: Vitesse
|
||||||
|
§ sidebar.person.day: Au jour le jour
|
||||||
|
§ sidebar.person.week: Une semaine
|
||||||
|
§ sidebar.person.month: Par mois
|
||||||
|
§ sidebar.person.hours: Horaire
|
||||||
|
§ sidebar.person.commits: all commits
|
||||||
|
§ sidebar.person.changes: Tous les changements
|
||||||
|
§ sidebar.person.words: Mots populaires
|
||||||
|
§ sidebar.person.settings: Réglages
|
||||||
|
`;
|
212
src/ts/translations/fr/pages.ts
Normal file
212
src/ts/translations/fr/pages.ts
Normal file
|
@ -0,0 +1,212 @@
|
||||||
|
export default `
|
||||||
|
§ page.welcome.step1: Execute the command in the root of your project.
|
||||||
|
§ page.welcome.step3: Drag and drop
|
||||||
|
§ page.welcome.step4: the log.txt file onto this page.
|
||||||
|
§ page.welcome.description: Git will create a log.txt file. It contains data for report generation. Or use git shortlog -s -n -e if you don't need a report. Create a [.mailmap|https://git-scm.com/docs/gitmailmap] file in the root of the project to consolidate employee statistics.
|
||||||
|
§ page.welcome.warning1: The service *DOES NOT SAVE* and *DOES NOT TRANSFER* your data. All calculations are performed locally in your browser on your machine.
|
||||||
|
§ page.welcome.warning2: The service *DOES NOT COLLECT STATISTICS* on projects. You can disconnect the internet, check traffic, and even build a local version from the [source|https://github.com/bakhirev/assayo].
|
||||||
|
§ page.common.words.title: Word Statistics.
|
||||||
|
§ page.common.words.description: the most popular word. Occurs $1 times.
|
||||||
|
§ page.common.commits.title: Number of commits by days.
|
||||||
|
§ page.common.commits.description: ($1) the most productive day in terms of the number of commits.
|
||||||
|
§ page.common.commits.title2: $1 commits made: $2
|
||||||
|
§ page.common.filter.allUsers: Does not matter
|
||||||
|
§ page.print.modal.title: What are we printing?
|
||||||
|
§ page.print.modal.page: Current page
|
||||||
|
§ page.print.modal.type: Current section
|
||||||
|
§ page.print.modal.all: All statistics
|
||||||
|
§ page.print.modal.cancel: Cancel
|
||||||
|
§ page.print.tableOfContents: Table of contents
|
||||||
|
§ page.print.title: Git repository report
|
||||||
|
§ page.print.sub_title: «$1»
|
||||||
|
§ page.print.description: The data for the report was obtained from the commit history.
|
||||||
|
§ page.team.author.title: Employee statistics
|
||||||
|
§ page.team.author.description1: *Part of the statistics* (work speed, costs, etc.) *for employees with the 'Assistant' type is not counted*, as it is an episodic role in the project. It is assumed that they do not affect the project, and their edits can be disregarded in the context of the overall volume of work.
|
||||||
|
§ page.team.author.description2: *Default sorting* is by the number of tasks and groups (current, fired, assisting employees).
|
||||||
|
§ page.team.author.types: Types of work
|
||||||
|
§ page.team.author.commits: Commits
|
||||||
|
§ page.team.author.commitsSmall: commits
|
||||||
|
§ page.team.author.tasks: Tasks
|
||||||
|
§ page.team.author.tasksSmall: tasks
|
||||||
|
§ page.team.author.workedLosses: Days with and without commits
|
||||||
|
§ page.team.author.worked: work
|
||||||
|
§ page.team.author.losses: days without commits
|
||||||
|
§ page.team.author.days: days
|
||||||
|
§ page.team.author.daysForTask: Days per task
|
||||||
|
§ page.team.author.scopes: Features
|
||||||
|
§ page.team.author.moneyAll: Received
|
||||||
|
§ page.team.author.moneyWorked: Worked for
|
||||||
|
§ page.team.author.moneyLosses: Overpayment
|
||||||
|
§ page.team.hours.title: Distribution of commits during each day of the week
|
||||||
|
§ page.team.month.title: Project work calendar
|
||||||
|
§ page.team.scope.title: Feature statistics
|
||||||
|
§ page.team.scope.scope: Feature
|
||||||
|
§ page.team.scope.days: Working Days
|
||||||
|
§ page.team.scope.authorsDays: Person-Days
|
||||||
|
§ page.team.scope.tasks: Tasks
|
||||||
|
§ page.team.scope.commits: Commits
|
||||||
|
§ page.team.scope.commitsSmall: commits
|
||||||
|
§ page.team.scope.types: Types of work
|
||||||
|
§ page.team.scope.authors: Personal contribution
|
||||||
|
§ page.team.scope.cost: Cost
|
||||||
|
§ page.team.type.title: Task type statistics
|
||||||
|
§ page.team.type.description: *Personal contribution* is counted by the number of commits, not the volume of changed lines or files. Therefore, the "File Analysis" section should also be consulted to assess the scale of changes.
|
||||||
|
§ page.team.type.type: Type of work
|
||||||
|
§ page.team.type.tasks: Tasks
|
||||||
|
§ page.team.type.tasksSmall: tasks
|
||||||
|
§ page.team.type.days: Days
|
||||||
|
§ page.team.type.daysSmall: days
|
||||||
|
§ page.team.type.authorsDays: Person-days
|
||||||
|
§ page.team.type.commits: Commits
|
||||||
|
§ page.team.type.authors: Personal contribution
|
||||||
|
§ page.team.total.titleA: Volume of work
|
||||||
|
§ page.team.total.titleB: Cost
|
||||||
|
§ page.team.total.daysWorked.title: person-days
|
||||||
|
§ page.team.total.daysWorked.description: Only days with commits are counted
|
||||||
|
§ page.team.total.commits.title: commits
|
||||||
|
§ page.team.total.commits.description: Deleted branches are not counted
|
||||||
|
§ page.team.total.daysLosses.title: days without commits
|
||||||
|
§ page.team.total.daysLosses.description: All days minus: holidays, weekends, vacation, days with commits
|
||||||
|
§ page.team.total.employment.title: working / dismissed
|
||||||
|
§ page.team.total.employment.description: If an employee does not make any commits within a month, they are considered dismissed
|
||||||
|
§ page.team.total.moneyAll.title: total
|
||||||
|
§ page.team.total.moneyAll.description: Total salary expenses
|
||||||
|
§ page.team.total.moneyWorked.title: actual
|
||||||
|
§ page.team.total.moneyWorked.description: Actual days worked multiplied by average salary
|
||||||
|
§ page.team.total.moneyLosses.title: possible overpayment
|
||||||
|
§ page.team.total.moneyLosses.description: Paid working days when there were no commits
|
||||||
|
§ page.team.total.weekendPayment.title: weekend work
|
||||||
|
§ page.team.total.weekendPayment.description: Total overpayment for weekend work
|
||||||
|
§ page.team.total.workSpeed.title: tasks per day
|
||||||
|
§ page.team.total.workSpeed.description: Average work speed of the team with the current composition of employees
|
||||||
|
§ page.team.total.moneySpeed.title: per month
|
||||||
|
§ page.team.total.moneySpeed.description: Forecasted salary payment amount with the current team composition, excluding taxes and related expenses
|
||||||
|
§ page.team.total.description1: *Person-days* — the work of one employee during a single working day. For example, in one calendar day, a team of three employees produces a work volume of three person-days.
|
||||||
|
§ page.team.total.description2: *Absentee days* are counted only as working days when commits could have been made. Weekends, public holidays, and vacations are not included in the calculation.
|
||||||
|
§ page.team.total.description3: The *working and dismissed* card shows the actual composition of employees who are continuously involved in work. Additionally, there are "assistants" — typically employees of a different specialization who may occasionally make commits to the project.
|
||||||
|
§ page.team.total.description4: *Overpayment* includes only working days when commits could have been made. Weekends, public holidays, and vacations are not included in the calculation. This is why overpayment + actual cost != total. The total cost includes payment for weekends, public holidays, and vacations.
|
||||||
|
§ page.team.total.description5: *Weekend work* is calculated at a rate of x2 the payment of a regular day. The displayed amount is specifically the overpayment (x1), as the fact of overtime in this context is not of interest. We focus on overpayment when increasing work speed.
|
||||||
|
§ page.team.tree.title: Project Tree Considering Selected Filters
|
||||||
|
§ page.team.tree.filters.author: Employee
|
||||||
|
§ page.team.tree.filters.commits: Number of commits
|
||||||
|
§ page.team.tree.filters.help: The minimum number of commits an employee has made in a file
|
||||||
|
§ page.team.tree.filters.all: All employees
|
||||||
|
§ page.team.tree.add: Who added
|
||||||
|
§ page.team.tree.change: Who changed
|
||||||
|
§ page.team.tree.remove: Who removed
|
||||||
|
§ page.team.tree.line: lines
|
||||||
|
§ page.team.tree.lineAdd: added
|
||||||
|
§ page.team.tree.lineRemove: changed
|
||||||
|
§ page.team.week.title: Weekly statistics
|
||||||
|
§ page.team.week.date: Date
|
||||||
|
§ page.team.week.numberTasks: Number of tasks
|
||||||
|
§ page.team.week.people: Number of people
|
||||||
|
§ page.team.week.line: Line Changes
|
||||||
|
§ page.team.week.days: Days with and without commits
|
||||||
|
§ page.team.week.lossesDetails: Who did not commit
|
||||||
|
§ page.team.week.add: added
|
||||||
|
§ page.team.week.change: changed
|
||||||
|
§ page.team.week.remove: removed
|
||||||
|
§ page.team.week.hasCommits: had commits
|
||||||
|
§ page.team.week.hasNotCommits: had no commits
|
||||||
|
§ page.team.week.days: days
|
||||||
|
§ page.team.week.tasks: tasks
|
||||||
|
§ page.team.pr.task: Task
|
||||||
|
§ page.team.pr.tasks: tasks
|
||||||
|
§ page.team.pr.firstCommitTime: First commit
|
||||||
|
§ page.team.pr.lastCommitTime: Last
|
||||||
|
§ page.team.pr.workDays: Development days
|
||||||
|
§ page.team.pr.delayDays: Days waiting for merge
|
||||||
|
§ page.team.pr.commits: Commits
|
||||||
|
§ page.team.pr.date: Merge Date
|
||||||
|
§ page.team.pr.mergeAuthor: Merged by
|
||||||
|
§ page.team.pr.author: Employee
|
||||||
|
§ page.team.pr.middleTimeRelease: Average delivery time (days)
|
||||||
|
§ page.team.pr.work: development
|
||||||
|
§ page.team.pr.delay: waiting
|
||||||
|
§ page.team.pr.days: days
|
||||||
|
§ page.team.pr.oneTaskDays: Time spent on one task
|
||||||
|
§ page.team.pr.description1: *Development time* is the time difference from the first to the last commit on a task. It does not matter if there were breaks of several days between commits or not. Any commit increases the time.
|
||||||
|
§ page.team.pr.description2: *Waiting time* is the time between the last commit and the code merge. It shows the actual downtime while waiting for something.
|
||||||
|
§ page.team.pr.description3: *Why display development time* without splitting into coding and code review? To show the business the actual delivery time of the code. Waiting for testing, review comments, DevOps problems, and other process imperfections are already included in this term.
|
||||||
|
§ page.team.pr.statByAuthors: Statistics by employees
|
||||||
|
§ page.team.pr.longDelay: Prolonged Waiting for merge
|
||||||
|
§ page.team.tasks.task: Task
|
||||||
|
§ page.team.tasks.author: First commit author
|
||||||
|
§ page.team.tasks.from: First commit
|
||||||
|
§ page.team.tasks.to: Last commit
|
||||||
|
§ page.team.tasks.daysInWork: Days in work
|
||||||
|
§ page.team.tasks.commits: Commits number
|
||||||
|
§ page.team.tasks.pr: Merge date
|
||||||
|
§ page.team.tasks.prAuthor: Merged by user
|
||||||
|
§ page.team.tasks.prDelayDays: Delay before merge in days
|
||||||
|
§ page.team.tasks.comments: Comments
|
||||||
|
§ page.person.print.photo.title: Photo
|
||||||
|
§ page.person.print.photo.description: space for a photo
|
||||||
|
§ page.person.total.title: Main characteristics
|
||||||
|
§ page.person.total.daysWorked.title: days of work
|
||||||
|
§ page.person.total.daysWorked.description: Only days with commits are counted
|
||||||
|
§ page.person.total.tasks.title: tasks
|
||||||
|
§ page.person.total.tasks.description: If commits are properly signed
|
||||||
|
§ page.person.character.title: Character
|
||||||
|
§ page.person.achievement.title: Achievements
|
||||||
|
§ page.person.achievement.positive: Positive
|
||||||
|
§ page.person.achievement.normal: Neutral
|
||||||
|
§ page.person.achievement.negative: Negative
|
||||||
|
§ page.person.achievement.description: The more negative achievements an employee accumulates, the higher the likelihood that the situation is unusual. It may be necessary to change their work mode, tasks, or reporting. A discussion with them to understand what problems are hindering their work is advisable.
|
||||||
|
§ page.person.gets.title: Gets taken:
|
||||||
|
§ page.person.gets.description: "Taking a get" in this context means being the first to leave a commit on a task with a "nice" number.
|
||||||
|
§ page.person.business.days.title: days of work
|
||||||
|
§ page.person.business.days.description: Only days with commits are counted
|
||||||
|
§ page.person.business.tasks.title: tasks
|
||||||
|
§ page.person.business.tasks.description: If commits are properly signed
|
||||||
|
§ page.person.business.losses.title: days without commits
|
||||||
|
§ page.person.business.losses.description: All days minus: holidays, weekends, vacation, days with commits
|
||||||
|
§ page.person.business.commits.title: commits
|
||||||
|
§ page.person.business.commits.description: Deleted branches are not counted
|
||||||
|
§ page.person.business.time.description: Time from the first to the last commit (including non-working days)
|
||||||
|
§ page.person.business.time.title: Days on the project:
|
||||||
|
§ page.person.business.time.dismissed: (dismissed)
|
||||||
|
§ page.person.business.time.staff: (not in the team)
|
||||||
|
§ page.person.business.achievements: Achievements
|
||||||
|
§ page.person.changes.title: Achievements
|
||||||
|
§ page.person.changes.description:
|
||||||
|
With some types of formatting, git marks lines as "deleted" and "added",
|
||||||
|
although in reality, they were "changed". Therefore, if you conducted a major refactoring,
|
||||||
|
git might show a small number of changes in the statistics, but the actual result
|
||||||
|
will be marked as a jump in "deleted" and "added" lines.
|
||||||
|
§ page.person.changes.description: List of commits and the number of changes in them for that day:
|
||||||
|
§ page.person.commits.title: List of commits:
|
||||||
|
§ page.person.money.title.total: Total over time
|
||||||
|
§ page.person.money.title.middle: Average cost
|
||||||
|
§ page.person.money.moneyAll.title: received
|
||||||
|
§ page.person.money.moneyAll.description: Assumed total salary from the project (see settings)
|
||||||
|
§ page.person.money.moneyWorked.title: worked for
|
||||||
|
§ page.person.money.moneyWorked.description: Actual days worked multiplied by average salary
|
||||||
|
§ page.person.money.moneyLosses.title: possible overpayment
|
||||||
|
§ page.person.money.moneyLosses.description: Days without commits multiplied by average salary
|
||||||
|
§ page.person.money.tasks.title: task
|
||||||
|
§ page.person.money.tasks.description: Number of closed tasks to the cost of the day
|
||||||
|
§ page.person.money.commits.title: commit
|
||||||
|
§ page.person.money.commits.description: Number of commits to the cost of the workday
|
||||||
|
§ page.person.speed.task: One task on average is
|
||||||
|
§ page.person.speed.max: Maximum speed per day
|
||||||
|
§ page.person.speed.days.title: days
|
||||||
|
§ page.person.speed.days.description: Refers to workdays, if commits are properly signed
|
||||||
|
§ page.person.speed.commits.title: commits
|
||||||
|
§ page.person.speed.commits.description: Top and bottom 10% of values are trimmed
|
||||||
|
§ page.person.speed.line.title: lines of code
|
||||||
|
§ page.person.speed.line.description: Top and bottom 10% of values are trimmed
|
||||||
|
§ page.person.speed.tasks.title: tasks
|
||||||
|
§ page.person.speed.tasks.description: A task may not be completed, but work should be done on it
|
||||||
|
§ page.person.speed.maxCommits.title: commits
|
||||||
|
§ page.person.speed.maxCommits.description: A task may not be completed, but work should be done on it
|
||||||
|
§ page.person.hours.title: Distribution of commits during each day of the week
|
||||||
|
§ page.person.week.date: Date
|
||||||
|
§ page.person.week.tasks: Number of tasks
|
||||||
|
§ page.person.week.workDays: Days with commits
|
||||||
|
§ page.person.week.taskInDay: Tasks per day
|
||||||
|
§ page.person.week.days: days
|
||||||
|
§ page.person.week.workDay: weekdays
|
||||||
|
§ page.person.week.weekends: weekends
|
||||||
|
`;
|
504
src/ts/translations/fr/recommendations.ts
Normal file
504
src/ts/translations/fr/recommendations.ts
Normal file
|
@ -0,0 +1,504 @@
|
||||||
|
export default `
|
||||||
|
§ recommendations.modal.cancel: Ok
|
||||||
|
§ recommendations.title
|
||||||
|
Recommendations and Facts
|
||||||
|
|
||||||
|
§ recommendations.timestamp.firstCommit.description
|
||||||
|
made the first commit
|
||||||
|
|
||||||
|
Day of the Week: $1
|
||||||
|
|
||||||
|
§ recommendations.timestamp.lastCommit.description
|
||||||
|
made the last commit
|
||||||
|
|
||||||
|
Day of the Week: $1
|
||||||
|
|
||||||
|
§ recommendations.timestamp.common.title: $1 days
|
||||||
|
§ recommendations.timestamp.allDays.description: from the first to the last commit (including weekends and holidays).
|
||||||
|
§ recommendations.timestamp.lossesDays.description: days without commits, even considering weekends, vacation, and public holidays.
|
||||||
|
§ recommendations.timestamp.weekendDays.description
|
||||||
|
working on weekends
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- employees burn out faster;
|
||||||
|
|
||||||
|
§ recommendations.timestamp.regularWeekendWord.title: Regular Overtime
|
||||||
|
§ recommendations.timestamp.sometimeWeekendWord.title: Occasional Overtime
|
||||||
|
§ recommendations.timestamp.weekendWord.description
|
||||||
|
It might be advisable to change the project manager, analyst, and architect.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- the quality of the product is usually low;
|
||||||
|
- some employees resign;
|
||||||
|
- new errors emerge due to the rush;
|
||||||
|
|
||||||
|
# Most likely:
|
||||||
|
- deadlines were incorrectly estimated at the beginning;
|
||||||
|
- technical specifications are missing;
|
||||||
|
- weak analytics;
|
||||||
|
- weak architecture (no architect was hired, and the team consists of mid-level developers);
|
||||||
|
- started writing code first, then planning;
|
||||||
|
- lack of proper processes to understand mistakes;
|
||||||
|
|
||||||
|
§ recommendations.timestamp.neverWeekendWord.title: Usually Without Overtime
|
||||||
|
§ recommendations.timestamp.neverWeekendWord.description
|
||||||
|
But sometimes it happens.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- employees burn out faster;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.not.title
|
||||||
|
No Parallel Work
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.not.description
|
||||||
|
any feature at any given time is done by one person.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is less than 1.3, we consider that there is usually no parallel work within most features;
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- increases bus factor;
|
||||||
|
- employees develop more slowly;
|
||||||
|
- difficult to properly check an employee's work;
|
||||||
|
|
||||||
|
# Why this is good:
|
||||||
|
- experts emerge who are deeply immersed in the subject area and can offer more quality solutions;
|
||||||
|
- most likely there are no merge conflicts;
|
||||||
|
- the project can quickly develop in different directions simultaneously;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.has.title
|
||||||
|
Some Work Done in Parallel
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.has.description
|
||||||
|
Sometimes a feature is worked on simultaneously by several people.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is from 1.3 to 2.0, we consider that some of the work within different features is sometimes done in parallel;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.every.title
|
||||||
|
Parallel Work
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.every.description
|
||||||
|
any feature at any given time is worked on by several people
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is more than two, we consider that most of the work within different features is usually done in parallel;
|
||||||
|
|
||||||
|
§ recommendations.scope.money
|
||||||
|
this is the estimated cost for the work on this project.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days spent on development are multiplied by the individual salaries of the developers;
|
||||||
|
|
||||||
|
To change the salary of each developer for a more accurate total, go to the "Settings" section.
|
||||||
|
|
||||||
|
# Is this too much or too little?
|
||||||
|
To answer this question, consider the following:
|
||||||
|
- Could a ready-made solution have been purchased for this amount of money?
|
||||||
|
- Could a better product have been developed for this amount of money?
|
||||||
|
|
||||||
|
If the answer to both questions is "yes," then perhaps developing from scratch was not worth the money spent.
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.everyHasOne.title
|
||||||
|
Bus factor = 1
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.everyHasOne.description
|
||||||
|
Most features are deeply understood by only one person.
|
||||||
|
It's necessary to rotate people.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- if employees resign, it will be difficult to continue their work;
|
||||||
|
- it’s impossible to control the quality of their code;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- more than 80% of commits in a feature are made by one person;
|
||||||
|
- the project has more than 60% of such features;
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.oneMaintainer
|
||||||
|
one person is deeply involved in a feature.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- if they resign, it will be hard to continue development;
|
||||||
|
- the quality of code-review decreases;
|
||||||
|
- it’s difficult to parallelize development when needed;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- more than 80% of commits in a feature are made by one person;
|
||||||
|
|
||||||
|
§ recommendations.scope.types.process.title
|
||||||
|
Poor Processes
|
||||||
|
|
||||||
|
§ recommendations.scope.types.process.description
|
||||||
|
Most features contain one type of task.
|
||||||
|
|
||||||
|
§ recommendations.scope.types.one
|
||||||
|
features contain one type of task.
|
||||||
|
|
||||||
|
§ recommendations.scope.types.common
|
||||||
|
It's possible that developers are incorrectly signing commits or the manager is entering the same type of tasks.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- it's impossible to hand over support to another team;
|
||||||
|
- it's impossible to release a "boxed" version;
|
||||||
|
- strong dependence on specific developers;
|
||||||
|
- a high number of errors and low code quality;
|
||||||
|
- potential slowdown in development in the future;
|
||||||
|
|
||||||
|
# The manager's mistake:
|
||||||
|
- viewing the product only from the perspective of a "working demo";
|
||||||
|
|
||||||
|
# What should be done:
|
||||||
|
- tests;
|
||||||
|
- bugs (identified through testing);
|
||||||
|
- refactoring (as architecture may change);
|
||||||
|
- documentation;
|
||||||
|
- style revisions (as a result of focus group feedback);
|
||||||
|
|
||||||
|
§ recommendations.scope.plan.title
|
||||||
|
Develop a Long-Term Plan
|
||||||
|
|
||||||
|
§ recommendations.scope.plan.description
|
||||||
|
taking architecture into account.
|
||||||
|
|
||||||
|
This plan should immediately focus on the most challenging tasks.
|
||||||
|
|
||||||
|
# Why the lack of a plan is bad:
|
||||||
|
- employees create a minimally viable version without planning for expansion points. After this, unscalable code is written, which slows down future features;
|
||||||
|
|
||||||
|
# The manager's mistake:
|
||||||
|
- they haven't shown how the product will develop further and where the growth points will be;
|
||||||
|
|
||||||
|
# How it should be done:
|
||||||
|
- a global product development plan is created;
|
||||||
|
- a global architecture development plan is created (with developers and DBAs);
|
||||||
|
- potential significant changes are discussed upfront at the schematic level;
|
||||||
|
|
||||||
|
§ recommendations.scope.cost.title
|
||||||
|
Evaluate Investment in a Feature
|
||||||
|
|
||||||
|
§ recommendations.scope.cost.description
|
||||||
|
in terms of potential profit.
|
||||||
|
|
||||||
|
Features that are expensive to develop but bring little profit may need to be postponed or even canceled. This will make the project more commercially successful.
|
||||||
|
|
||||||
|
§ recommendations.author.lotOfLazy
|
||||||
|
writes too little code.
|
||||||
|
|
||||||
|
# Should they be fired?
|
||||||
|
- are they a team leader, architect, or analyst?
|
||||||
|
- is this their primary project?
|
||||||
|
- are there any dependencies on them?
|
||||||
|
|
||||||
|
# Why it makes no sense to correct
|
||||||
|
The total costs for the developer are already more than the profit from their work.
|
||||||
|
If we believe that there were no objective hindrances to their work, then the person either does not want to work at all or is working on two projects simultaneously.
|
||||||
|
Firing and replacing them with a new employee seems justified from a statistical point of view.
|
||||||
|
|
||||||
|
§ recommendations.author.manyLazy
|
||||||
|
writes little code. Needs to be monitored.
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- in test samples, a good programmer writes code for more than 80% of the time;
|
||||||
|
- in this case, the indicator is between 60% and 80%;
|
||||||
|
|
||||||
|
# How to monitor:
|
||||||
|
- break tasks into 1..2 days;
|
||||||
|
- ask for a status update every day;
|
||||||
|
- ensure tasks are well defined and ready for development;
|
||||||
|
- arrange pair programming to check actual speed;
|
||||||
|
|
||||||
|
§ recommendations.author.oneTypeMans
|
||||||
|
receives too many monotonous tasks of the same type. Risk of burnout.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- if an employee burns out, their work speed will decrease;
|
||||||
|
- professional growth slows down;
|
||||||
|
- the likelihood of resignation increases;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- the type of task is determined for each commit;
|
||||||
|
- if more than 70% of tasks are of the same type, it means the person is doing the same thing repeatedly;
|
||||||
|
|
||||||
|
§ recommendations.author.workToday.title: Working $1
|
||||||
|
§ recommendations.author.workToday.description
|
||||||
|
on the project at this moment.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- more than 50% of workdays;
|
||||||
|
- have worked during the last 30 days;
|
||||||
|
|
||||||
|
§ recommendations.author.dismissed.title: Dismissed $1
|
||||||
|
§ recommendations.author.dismissed.description
|
||||||
|
or worked for a short period.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- worked at a normal pace (apparently, this is their main repository);
|
||||||
|
- no commits in the last month;
|
||||||
|
- vacation usually lasts 14 days (their absence does not resemble a vacation);
|
||||||
|
|
||||||
|
§ recommendations.author.staff.title: Assisting $1
|
||||||
|
§ recommendations.author.staff.description
|
||||||
|
People of other specializations who have committed something.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- this is not an open-source project;
|
||||||
|
- workdays less than 15% of the total number;
|
||||||
|
- modify roughly the same files;
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.openSource.title
|
||||||
|
Open Project
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.openSource.description
|
||||||
|
they do not work five days a week here.
|
||||||
|
|
||||||
|
The project may be closed, but this work pace is typical for open libraries on GitHub.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- statistics are taken for all active developers;
|
||||||
|
- the average number of working days and days without commits is calculated;
|
||||||
|
- for open-source libraries, working days are usually a maximum of 15..20%;
|
||||||
|
|
||||||
|
# Consequences
|
||||||
|
For projects where work is not constant, many indicators do not make sense. Therefore, indicators like days without commits, speed, etc., will be hidden.
|
||||||
|
|
||||||
|
Typically, such projects are assessed before starting the development of their own closed version. The most interesting indicators in this case are the probable cost and total development time.
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.easy.title
|
||||||
|
Light Workload
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.easy.description
|
||||||
|
too many days without commits. It is necessary to understand why the team is not writing code.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- take statistics from all active developers;
|
||||||
|
- calculate the average number of working days and days without commits;
|
||||||
|
- workload is considered light if the percentage of days without commits is between 5% and 20%;
|
||||||
|
|
||||||
|
# Possible reasons:
|
||||||
|
- there are actually no tasks;
|
||||||
|
- there are tasks, but they fit well with the current architecture;
|
||||||
|
- developers are distracted by meetings;
|
||||||
|
- the team is not working;
|
||||||
|
|
||||||
|
# Solutions:
|
||||||
|
- discuss the issue with the team;
|
||||||
|
- reduce task granularity so that one or two tasks can be completed in a day;
|
||||||
|
- introduce daily meetings to check the status of tasks;
|
||||||
|
- arrange pair programming sessions to ensure that the developer can work faster;
|
||||||
|
|
||||||
|
§ recommendations.author.manager.title
|
||||||
|
Set Deadlines
|
||||||
|
|
||||||
|
§ recommendations.author.manager.description
|
||||||
|
Every task should have a clear deadline.
|
||||||
|
|
||||||
|
This will prevent dragging out its completion for several days or weeks.
|
||||||
|
|
||||||
|
# Indicators to check:
|
||||||
|
- the number of days spent on one task by an employee;
|
||||||
|
- the number of days waiting for PR merge (PR statistics page);
|
||||||
|
|
||||||
|
§ recommendations.author.shorTalk.title
|
||||||
|
Conduct Daily Meetings
|
||||||
|
|
||||||
|
§ recommendations.author.shorTalk.description
|
||||||
|
they help stay informed about the project.
|
||||||
|
|
||||||
|
Do not stretch them by getting sidetracked on irrelevant topics.
|
||||||
|
|
||||||
|
# Questions the employee should answer:
|
||||||
|
- what was done;
|
||||||
|
- what will be done;
|
||||||
|
- are there any issues;
|
||||||
|
|
||||||
|
# Interruptions should occur if:
|
||||||
|
- they start describing minor details in-depth, which are not important;
|
||||||
|
- they steer the conversation away from the original plan;
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
Often an employee who does nothing tries to avoid the answer by telling a bunch of unnecessary details of their work. This lulls the participants' attention and stretches the time for a response. It creates an impression that they are busy, even though there was no actual work done.
|
||||||
|
|
||||||
|
§ recommendations.author.ipr.title
|
||||||
|
Develop a Training Plan
|
||||||
|
|
||||||
|
§ recommendations.author.ipr.description
|
||||||
|
for each employee.
|
||||||
|
|
||||||
|
*Individual training plan* is a list of goals and tasks that help a person develop in a certain area.
|
||||||
|
|
||||||
|
# How to create a plan:
|
||||||
|
- create a competency matrix;
|
||||||
|
- identify which competencies have the least knowledge and experience;
|
||||||
|
- find out which of these competencies are of interest to the employee;
|
||||||
|
- come up with 3..5 goals within each such competency for the next six months or a year;
|
||||||
|
- try to do something every month to achieve one goal;
|
||||||
|
- remind every month about the overall plan to achieve these goals;
|
||||||
|
|
||||||
|
# Does a manager need a plan?
|
||||||
|
Yes, the manager should also make a plan for themselves. If there is no higher-level manager, they should self-assess.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- employees become more loyal to the company;
|
||||||
|
- you get more qualified personnel for the same money;
|
||||||
|
|
||||||
|
§ recommendations.author.oneToOne.title
|
||||||
|
Conduct One-on-One Meetings Every Month
|
||||||
|
|
||||||
|
§ recommendations.author.oneToOne.description
|
||||||
|
it helps to identify problems at an early stage.
|
||||||
|
|
||||||
|
*One-to-one* is a regular personal meeting of a manager with a subordinate. Such meetings typically discuss everything important to the employee, what concerns them, and what they can share with the manager in private.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- easy to find out who is overburdened and who has free time;
|
||||||
|
- possible to prevent employee burnout;
|
||||||
|
- quick feedback can be obtained about processes that you might not notice;
|
||||||
|
- trust is built, making employees more loyal to the company;
|
||||||
|
- increases employee motivation and engagement;
|
||||||
|
|
||||||
|
§ recommendations.author.club.title
|
||||||
|
Go to a Bar
|
||||||
|
|
||||||
|
§ recommendations.author.club.description
|
||||||
|
once a month or two.
|
||||||
|
|
||||||
|
This will help build informal communication within the team and bring the team together, even if the interaction is brief.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- quick feedback can be obtained about processes that you might not notice;
|
||||||
|
- trust is built, making employees more loyal to the company;
|
||||||
|
- increases employee engagement;
|
||||||
|
|
||||||
|
§ recommendations.hour.onlyWork.title: No Weekends Here
|
||||||
|
§ recommendations.hour.onlyWork.description: The project manager should probably be fired.
|
||||||
|
§ recommendations.hour.weekends.title: Working on Weekends
|
||||||
|
§ recommendations.hour.weekends.description: The project manager should probably be checked.
|
||||||
|
§ recommendations.hour.easy.title: There Are Problems
|
||||||
|
§ recommendations.hour.easy.description: There are likely crunch times and work is needed on weekends.
|
||||||
|
§ recommendations.week.lazyDays.down.title: Fewer Absences
|
||||||
|
§ recommendations.week.lazyDays.down.description: this indicator has dropped over the last three weeks
|
||||||
|
§ recommendations.week.lazyDays.up.title: More Absences
|
||||||
|
§ recommendations.week.lazyDays.up.description: no tasks or stricter control is needed
|
||||||
|
§ recommendations.week.notWork.title: Consistently Underperforms
|
||||||
|
§ recommendations.week.notWork.description: as every week the code is not 100% of the time
|
||||||
|
§ recommendations.week.upWork.title: Consistently Overworks
|
||||||
|
§ recommendations.week.upWork.description: as every week code is written on weekend days
|
||||||
|
§ recommendations.week.task.up.title: Productivity is growing
|
||||||
|
§ recommendations.week.task.up.description: or tasks have become too small. Need to check. If granularity is the same - reinforce the result.
|
||||||
|
§ recommendations.week.task.lazyMaintainer.description: consistently leads in absences. Fire?
|
||||||
|
§ recommendations.week.task.down.title: Productivity is Falling
|
||||||
|
§ recommendations.week.task.down.description
|
||||||
|
or tasks are poorly split. Need to check. If granularity is the same - take control.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- the number of tasks per day that are being worked on has been steadily decreasing over the last three weeks.
|
||||||
|
|
||||||
|
# Possible errors:
|
||||||
|
- tasks could have been more complex than they seemed;
|
||||||
|
- tasks could have had a large volume of work (need to check if the number of changes is also decreasing during this period)
|
||||||
|
|
||||||
|
§ recommendations.type.everyHasOne.title: Not Signing Task Types
|
||||||
|
§ recommendations.type.everyHasOne.description: Most task types are done by one person.
|
||||||
|
§ recommendations.type.oneMaintainer.title: Narrow Specialization
|
||||||
|
§ recommendations.type.oneMaintainer.description
|
||||||
|
most tasks of one type are done by the same people.
|
||||||
|
|
||||||
|
# Task types:
|
||||||
|
|
||||||
|
§ recommendations.type.common
|
||||||
|
# It might not be the case
|
||||||
|
|
||||||
|
Make sure that other employees correctly sign commits.
|
||||||
|
|
||||||
|
Steps to ensure this:
|
||||||
|
- set up a pre-commit check for commit messages;
|
||||||
|
- explain to the team the need to indicate the type;
|
||||||
|
- check in new branches that employees follow this rule;
|
||||||
|
|
||||||
|
# If it is indeed the case
|
||||||
|
|
||||||
|
You have set up checks and ensured that the same employee does tasks of the same type.
|
||||||
|
|
||||||
|
Why this is bad:
|
||||||
|
- their resignation will halt a whole bunch of processes;
|
||||||
|
- it reduces the competence of other team members;
|
||||||
|
- difficult to understand their edits at a higher level;
|
||||||
|
|
||||||
|
How to fix this:
|
||||||
|
- distribute different types of tasks evenly;
|
||||||
|
- change the area of work (tests, documentation, bugs) among employees every sprint;
|
||||||
|
|
||||||
|
§ recommendations.type.fewTypes.title
|
||||||
|
This is a Local Product
|
||||||
|
|
||||||
|
§ recommendations.type.fewTypes.description
|
||||||
|
for a specific customer or problem.
|
||||||
|
|
||||||
|
# Signs of a "global" product:
|
||||||
|
- localization;
|
||||||
|
- documentation;
|
||||||
|
- a large volume of tests;
|
||||||
|
- visual customization;
|
||||||
|
- refactoring of bottlenecks;
|
||||||
|
- etc.
|
||||||
|
|
||||||
|
# Why this product looks like a "local" one:
|
||||||
|
- each "global" sign will be outweighed by its type of task;
|
||||||
|
- the more "global" signs, the more likely a "global" product;
|
||||||
|
|
||||||
|
In this case, we see a small number of types, which likely indicates shortcomings that prevent the product from being easily scaled to the global market and sold in other countries.
|
||||||
|
|
||||||
|
# It might not be the case
|
||||||
|
Based on file types, we can assume the type of program (website, server application, DevOps scripts, etc.). For a frontend application, our hypothesis will be more accurate than for DevOps scripts, which might just be a micro-module of initialization.
|
||||||
|
|
||||||
|
§ recommendations.type.diff.title
|
||||||
|
Break Down the Leading Type into Subtypes
|
||||||
|
|
||||||
|
§ recommendations.type.diff.description
|
||||||
|
to detail errors.
|
||||||
|
|
||||||
|
Typically, the task type labeled "bug fixing" is leading. This makes the statistics weakly detailed.
|
||||||
|
|
||||||
|
*If you encounter this situation*, you can break down this type into subtypes (e.g., based on the location of detection).
|
||||||
|
|
||||||
|
Consider several options for subtypes:
|
||||||
|
- fix_dev (error detected during development);
|
||||||
|
- fix_test (error detected during testing);
|
||||||
|
- fix (error detected in production);
|
||||||
|
|
||||||
|
§ recommendations.type.buddy.title
|
||||||
|
Accumulate Minor Tasks
|
||||||
|
|
||||||
|
§ recommendations.type.buddy.description
|
||||||
|
for new employees.
|
||||||
|
|
||||||
|
# If a task is:
|
||||||
|
- not important;
|
||||||
|
- not big;
|
||||||
|
- doesn't require deep immersion in the context;
|
||||||
|
- more about refactoring than new code;
|
||||||
|
|
||||||
|
# Put it in the backlog with the label "for beginners".
|
||||||
|
|
||||||
|
When a new employee arrives, you will be able to immediately pull out a bunch of small and varied tasks for them to get acquainted with the project.
|
||||||
|
|
||||||
|
Also, if you have a lull in work, you can pull out one such minor task from the backlog.
|
||||||
|
`;
|
27
src/ts/translations/fr/settings.ts
Normal file
27
src/ts/translations/fr/settings.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ page.settings.document.title: Display settings
|
||||||
|
§ page.settings.document.name: Page title
|
||||||
|
§ page.settings.document.language: Interface language
|
||||||
|
§ page.settings.links.title: Link prefixes
|
||||||
|
§ page.settings.links.task: For task numbers
|
||||||
|
§ page.settings.links.pr: For PR
|
||||||
|
§ page.settings.user.title: Individual settings
|
||||||
|
§ page.settings.user.notFound: No individual settings. Data for all employees are calculated based on common parameters.
|
||||||
|
§ page.settings.user.subTitle: Addendum to employment contract №$1
|
||||||
|
§ page.settings.user.from: Start date
|
||||||
|
§ page.settings.mailmap: .mailmap example
|
||||||
|
§ page.settings.common.title: General salary data
|
||||||
|
§ page.settings.common.type.title: Project work type
|
||||||
|
§ page.settings.common.type.full: Full-time employment
|
||||||
|
§ page.settings.common.type.part: Project work
|
||||||
|
§ page.settings.common.salary: Monthly salary
|
||||||
|
§ page.settings.common.currency: Currency
|
||||||
|
§ page.settings.common.workDaysInYear: Number of working days in a year
|
||||||
|
§ page.settings.common.vacationDaysInYear: Number of vacation days in a year
|
||||||
|
§ page.settings.common.workDaysInWeek: Workdays
|
||||||
|
§ page.settings.form.save: Save
|
||||||
|
§ page.settings.form.cancel: Cancel
|
||||||
|
§ page.settings.form.remove: Remove
|
||||||
|
§ page.settings.form.addEmployee: Add an employee
|
||||||
|
§ page.settings.form.addContract: Add an employment contract
|
||||||
|
`;
|
92
src/ts/translations/ja/achievements.ts
Normal file
92
src/ts/translations/ja/achievements.ts
Normal file
|
@ -0,0 +1,92 @@
|
||||||
|
export default `
|
||||||
|
§ achievements.commitsAfter1500.title: Owl
|
||||||
|
§ achievements.commitsAfter1500.description: 70% of commits after 3:00 PM
|
||||||
|
§ achievements.commitsBefore1500.title: Early bird
|
||||||
|
§ achievements.commitsBefore1500.description: 70% of commits before noon
|
||||||
|
§ achievements.workEveryTime.title: Devoted worker
|
||||||
|
§ achievements.workEveryTime.description: a commit for every hour of the day
|
||||||
|
§ achievements.workNotWork.title: Shooting blanks
|
||||||
|
§ achievements.workNotWork.description: commits are there, but no tasks are closed
|
||||||
|
§ achievements.userNotWork.title: Fly-by
|
||||||
|
§ achievements.userNotWork.description: this is not their main project
|
||||||
|
§ achievements.userIsDied.title: Dead soul
|
||||||
|
§ achievements.userIsDied.description: worked, but resigned
|
||||||
|
§ achievements.lessTasks.title: Came and went
|
||||||
|
§ achievements.lessTasks.description: least closed tasks
|
||||||
|
§ achievements.moreTasks.title: Father says well done
|
||||||
|
§ achievements.moreTasks.description: most closed tasks
|
||||||
|
§ achievements.everyMessageLong.title: Master of eloquence
|
||||||
|
§ achievements.everyMessageLong.description: consistently the longest commit messages
|
||||||
|
§ achievements.everyMessageShort.title: Talkative, a spy's dream
|
||||||
|
§ achievements.everyMessageShort.description: consistently, the shortest commit messages
|
||||||
|
§ achievements.shortestName.title: Size doesn't matter
|
||||||
|
§ achievements.shortestName.description: shortest name
|
||||||
|
§ achievements.longestName.title: Azim Aziz Il Am Kadir Imran II
|
||||||
|
§ achievements.longestName.description: longest name
|
||||||
|
§ achievements.moreCommits.title: Backup master
|
||||||
|
§ achievements.moreCommits.description: most commits
|
||||||
|
§ achievements.lessCommits.title: Rare but Precise
|
||||||
|
§ achievements.lessCommits.description: least commits
|
||||||
|
§ achievements.oneCommitOneTask.title: Right on target
|
||||||
|
§ achievements.oneCommitOneTask.description: on average one commit per task
|
||||||
|
§ achievements.moreLazyDays.title: With you in spirit
|
||||||
|
§ achievements.moreLazyDays.description: most days without commits
|
||||||
|
§ achievements.lessLazyDays.title: Papa carlo
|
||||||
|
§ achievements.lessLazyDays.description: least days without commits
|
||||||
|
§ achievements.zeroLazyDays.title: Not a single break
|
||||||
|
§ achievements.zeroLazyDays.description: not a single day without commits
|
||||||
|
§ achievements.moreWorkDays.title: Valuable employee
|
||||||
|
§ achievements.moreWorkDays.description: most working days
|
||||||
|
§ achievements.moreScopes.title: Startuper
|
||||||
|
§ achievements.moreScopes.description: completed the most features
|
||||||
|
§ achievements.lessScopes.title: Dandy
|
||||||
|
§ achievements.lessScopes.description: completed the fewest features
|
||||||
|
§ achievements.moreDaysForTask.title: Snail on the slope
|
||||||
|
§ achievements.moreDaysForTask.description: tasks take longer than others
|
||||||
|
§ achievements.more2DaysForTask.title: Slow and steady
|
||||||
|
§ achievements.more2DaysForTask.description: more than two days per task
|
||||||
|
§ achievements.moreDaysInProject.title: Old-timer
|
||||||
|
§ achievements.moreDaysInProject.description: most days in the project
|
||||||
|
§ achievements.lessDaysInProject.title: And who is this?
|
||||||
|
§ achievements.lessDaysInProject.description: least days in the project
|
||||||
|
§ achievements.more90DaysInProject.title: Welcome aboard
|
||||||
|
§ achievements.more90DaysInProject.description: not fired during the probation period
|
||||||
|
§ achievements.lessDaysForTask.title: Quick draw
|
||||||
|
§ achievements.lessDaysForTask.description: a task takes less than a day
|
||||||
|
§ achievements.adam.title: Adam
|
||||||
|
§ achievements.adam.description: the first stable employee on the project
|
||||||
|
§ achievements.more666DaysInProject.title: Devil
|
||||||
|
§ achievements.more666DaysInProject.description: worked 666 days on the project
|
||||||
|
§ achievements.more777DaysInProject.title: Azino three axes
|
||||||
|
§ achievements.more777DaysInProject.description: worked 777 days on the project
|
||||||
|
§ achievements.moreRefactoring.title: Executive editor
|
||||||
|
§ achievements.moreRefactoring.description: made the most 'refactoring' tags
|
||||||
|
§ achievements.longestMessage.title: So many conversations...
|
||||||
|
§ achievements.longestMessage.description: the longest commit message of all time
|
||||||
|
§ achievements.moreTasksInDay.title: Speed racer
|
||||||
|
§ achievements.moreTasksInDay.description: record for the number of tasks closed in a day
|
||||||
|
§ achievements.hasCommitFrom0to7.title: Night watch
|
||||||
|
§ achievements.hasCommitFrom0to7.description: a commit for every hour of the night
|
||||||
|
§ achievements.noCommitOnDay.title: Technical break
|
||||||
|
§ achievements.noCommitOnDay.description: there is a certain hour and day in working time when never commits
|
||||||
|
§ achievements.hasCommitEveryTime.title: Died at work
|
||||||
|
§ achievements.hasCommitEveryTime.description: a commit for every hour of each day (including weekends)
|
||||||
|
§ achievements.commitsAfter1800.title: Business Time
|
||||||
|
§ achievements.commitsAfter1800.description: no commits after 6:00 PM
|
||||||
|
§ achievements.more1488DaysInProject.title: Named after Maxim Martsinkevich
|
||||||
|
§ achievements.more1488DaysInProject.description: worked 1488 days on the project
|
||||||
|
§ achievements.moreFix.title: Bug hunter
|
||||||
|
§ achievements.moreFix.description: most closed bugs
|
||||||
|
§ achievements.lessWorkDays.title: Count me out
|
||||||
|
§ achievements.lessWorkDays.description: least working days
|
||||||
|
§ achievements.moreCreateCode.title: Creator
|
||||||
|
§ achievements.moreCreateCode.description: tends to add code more than others
|
||||||
|
§ achievements.moreRemoveCode.title: Destroyer
|
||||||
|
§ achievements.moreRemoveCode.description: tends to remove code more than others
|
||||||
|
§ achievements.moreChangeCode.title: Reformer
|
||||||
|
§ achievements.moreChangeCode.description: tends to change code more than others
|
||||||
|
§ achievements.moreStyle.title: Fashion police
|
||||||
|
§ achievements.moreStyle.description: tends to change CSS more than others
|
||||||
|
§ achievements.moreOnHoliday.title: No life
|
||||||
|
§ achievements.moreOnHoliday.description: relatively many commits in non-working hours
|
||||||
|
`;
|
27
src/ts/translations/ja/common.ts
Normal file
27
src/ts/translations/ja/common.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ uiKit.console.button: コピー
|
||||||
|
§ uiKit.console.notification: テキストがコピーされました
|
||||||
|
§ uiKit.dataLoader.page: ページ
|
||||||
|
§ uiKit.dataLoader.size: によって表示される
|
||||||
|
§ uiKit.dataLoader.from: から
|
||||||
|
§ uiKit.dataLoader.all: すべて表示
|
||||||
|
§ uiKit.hoursChart.work: 標準労働時間 (平日,から07:00へ20:00)
|
||||||
|
§ uiKit.hoursChart.weekend: 休業日または営業日前後の時間
|
||||||
|
§ uiKit.hoursChart.days: 特定日時における総コミット数を日本語に翻訳してください。
|
||||||
|
§ uiKit.page.remove: 削除
|
||||||
|
§ uiKit.nothingFound.common.title: 表示するデータがない、または不十分なデータがあります
|
||||||
|
§ uiKit.nothingFound.common.description: コミットが次の形式で署名されている場合、システムはより多くのデータを処理します [Git commit message convention|https://www.conventionalcommits.org/en/v1.0.0/]. パターン:
|
||||||
|
§ uiKit.nothingFound.common.console: Task_numberタイプ(モジュール): 説明
|
||||||
|
§ uiKit.nothingFound.common.example: 説明:
|
||||||
|
§ uiKit.nothingFound.staff.title: この従業員のデータはありません
|
||||||
|
§ uiKit.nothingFound.staff.description1:
|
||||||
|
彼は、毎日作業日のうち правки を行いませんでした。したがって、 “助手” という勤務種別を取得しました。
|
||||||
|
そのような職種を持つ従業員の統計は無視できます。彼の知識は微妙です。
|
||||||
|
§ uiKit.nothingFound.staff.description2:
|
||||||
|
システムはそれのためのいくつかの指標を計算しません。
|
||||||
|
もしそれがエラーであり、その従業員に関する統計を扱う必要がある場合、“設定” セクションに移動してタイプを変更してください。
|
||||||
|
§ common.title: Git 統計
|
||||||
|
§ common.filters: フィルター
|
||||||
|
§ common.notifications.save: 変更は保存されます
|
||||||
|
§ common.notifications.setting: 設定が保存されます
|
||||||
|
`;
|
15
src/ts/translations/ja/index.ts
Normal file
15
src/ts/translations/ja/index.ts
Normal file
|
@ -0,0 +1,15 @@
|
||||||
|
import achievements from './achievements';
|
||||||
|
import common from './common';
|
||||||
|
import navigation from './navigation';
|
||||||
|
import recommendations from './recommendations';
|
||||||
|
import settings from './settings';
|
||||||
|
import pages from './pages';
|
||||||
|
|
||||||
|
export default [
|
||||||
|
achievements,
|
||||||
|
common,
|
||||||
|
navigation,
|
||||||
|
recommendations,
|
||||||
|
settings,
|
||||||
|
pages,
|
||||||
|
].join('');
|
40
src/ts/translations/ja/navigation.ts
Normal file
40
src/ts/translations/ja/navigation.ts
Normal file
|
@ -0,0 +1,40 @@
|
||||||
|
export default `
|
||||||
|
§ sidebar.switch.team: チーム
|
||||||
|
§ sidebar.switch.person: 従業員
|
||||||
|
§ sidebar.buttons.settings: 設定
|
||||||
|
§ sidebar.buttons.print: 印刷
|
||||||
|
§ sidebar.filters.all: すべての時間
|
||||||
|
§ sidebar.filters.year: 年
|
||||||
|
§ sidebar.filters.halfYear: 半年
|
||||||
|
§ sidebar.filters.month: 月
|
||||||
|
§ sidebar.filters.week: 一週間
|
||||||
|
§ sidebar.team.total: 一般的な情報
|
||||||
|
§ sidebar.team.scope: モジュール
|
||||||
|
§ sidebar.team.author: スタッフ
|
||||||
|
§ sidebar.team.type: タスクの種類
|
||||||
|
§ sidebar.team.pr: コード注入
|
||||||
|
§ sidebar.team.day: 日によって
|
||||||
|
§ sidebar.team.week: 週ごと
|
||||||
|
§ sidebar.team.month: 月別
|
||||||
|
§ sidebar.team.tree: ファイルの分析
|
||||||
|
§ sidebar.team.files: ファイル
|
||||||
|
§ sidebar.team.removedFiles: 削除されたファイル
|
||||||
|
§ sidebar.team.tasks: タスクリスト
|
||||||
|
§ sidebar.team.hours: スケジュール
|
||||||
|
§ sidebar.team.commits: All commits
|
||||||
|
§ sidebar.team.changes: すべての変更
|
||||||
|
§ sidebar.team.words: 人気のある言葉
|
||||||
|
§ sidebar.team.top: クイズ
|
||||||
|
§ sidebar.team.settings: 設定
|
||||||
|
§ sidebar.person.total: 一般的な情報
|
||||||
|
§ sidebar.person.money: 仕事のコスト
|
||||||
|
§ sidebar.person.speed: スピード
|
||||||
|
§ sidebar.person.day: 日によって
|
||||||
|
§ sidebar.person.week: 週ごと
|
||||||
|
§ sidebar.person.month: 月別
|
||||||
|
§ sidebar.person.hours: スケジュール
|
||||||
|
§ sidebar.person.commits: All commits
|
||||||
|
§ sidebar.person.changes: すべての変更
|
||||||
|
§ sidebar.person.words: 人気のある言葉
|
||||||
|
§ sidebar.person.settings: 設定
|
||||||
|
`;
|
212
src/ts/translations/ja/pages.ts
Normal file
212
src/ts/translations/ja/pages.ts
Normal file
|
@ -0,0 +1,212 @@
|
||||||
|
export default `
|
||||||
|
§ page.welcome.step1: Execute the command in the root of your project.
|
||||||
|
§ page.welcome.step3: Drag and drop
|
||||||
|
§ page.welcome.step4: the log.txt file onto this page.
|
||||||
|
§ page.welcome.description: Git will create a log.txt file. It contains data for report generation. Or use git shortlog -s -n -e if you don't need a report. Create a [.mailmap|https://git-scm.com/docs/gitmailmap] file in the root of the project to consolidate employee statistics.
|
||||||
|
§ page.welcome.warning1: The service *DOES NOT SAVE* and *DOES NOT TRANSFER* your data. All calculations are performed locally in your browser on your machine.
|
||||||
|
§ page.welcome.warning2: The service *DOES NOT COLLECT STATISTICS* on projects. You can disconnect the internet, check traffic, and even build a local version from the [source|https://github.com/bakhirev/assayo].
|
||||||
|
§ page.common.words.title: Word Statistics.
|
||||||
|
§ page.common.words.description: the most popular word. Occurs $1 times.
|
||||||
|
§ page.common.commits.title: Number of commits by days.
|
||||||
|
§ page.common.commits.description: ($1) the most productive day in terms of the number of commits.
|
||||||
|
§ page.common.commits.title2: $1 commits made: $2
|
||||||
|
§ page.common.filter.allUsers: Does not matter
|
||||||
|
§ page.print.modal.title: What are we printing?
|
||||||
|
§ page.print.modal.page: Current page
|
||||||
|
§ page.print.modal.type: Current section
|
||||||
|
§ page.print.modal.all: All statistics
|
||||||
|
§ page.print.modal.cancel: Cancel
|
||||||
|
§ page.print.tableOfContents: Table of contents
|
||||||
|
§ page.print.title: Git repository report
|
||||||
|
§ page.print.sub_title: «$1»
|
||||||
|
§ page.print.description: The data for the report was obtained from the commit history.
|
||||||
|
§ page.team.author.title: Employee statistics
|
||||||
|
§ page.team.author.description1: *Part of the statistics* (work speed, costs, etc.) *for employees with the 'Assistant' type is not counted*, as it is an episodic role in the project. It is assumed that they do not affect the project, and their edits can be disregarded in the context of the overall volume of work.
|
||||||
|
§ page.team.author.description2: *Default sorting* is by the number of tasks and groups (current, fired, assisting employees).
|
||||||
|
§ page.team.author.types: Types of work
|
||||||
|
§ page.team.author.commits: Commits
|
||||||
|
§ page.team.author.commitsSmall: commits
|
||||||
|
§ page.team.author.tasks: Tasks
|
||||||
|
§ page.team.author.tasksSmall: tasks
|
||||||
|
§ page.team.author.workedLosses: Days with and without commits
|
||||||
|
§ page.team.author.worked: work
|
||||||
|
§ page.team.author.losses: days without commits
|
||||||
|
§ page.team.author.days: days
|
||||||
|
§ page.team.author.daysForTask: Days per task
|
||||||
|
§ page.team.author.scopes: Features
|
||||||
|
§ page.team.author.moneyAll: Received
|
||||||
|
§ page.team.author.moneyWorked: Worked for
|
||||||
|
§ page.team.author.moneyLosses: Overpayment
|
||||||
|
§ page.team.hours.title: Distribution of commits during each day of the week
|
||||||
|
§ page.team.month.title: Project work calendar
|
||||||
|
§ page.team.scope.title: Feature statistics
|
||||||
|
§ page.team.scope.scope: Feature
|
||||||
|
§ page.team.scope.days: Working Days
|
||||||
|
§ page.team.scope.authorsDays: Person-Days
|
||||||
|
§ page.team.scope.tasks: Tasks
|
||||||
|
§ page.team.scope.commits: Commits
|
||||||
|
§ page.team.scope.commitsSmall: commits
|
||||||
|
§ page.team.scope.types: Types of work
|
||||||
|
§ page.team.scope.authors: Personal contribution
|
||||||
|
§ page.team.scope.cost: Cost
|
||||||
|
§ page.team.type.title: Task type statistics
|
||||||
|
§ page.team.type.description: *Personal contribution* is counted by the number of commits, not the volume of changed lines or files. Therefore, the "File Analysis" section should also be consulted to assess the scale of changes.
|
||||||
|
§ page.team.type.type: Type of work
|
||||||
|
§ page.team.type.tasks: Tasks
|
||||||
|
§ page.team.type.tasksSmall: tasks
|
||||||
|
§ page.team.type.days: Days
|
||||||
|
§ page.team.type.daysSmall: days
|
||||||
|
§ page.team.type.authorsDays: Person-days
|
||||||
|
§ page.team.type.commits: Commits
|
||||||
|
§ page.team.type.authors: Personal contribution
|
||||||
|
§ page.team.total.titleA: Volume of work
|
||||||
|
§ page.team.total.titleB: Cost
|
||||||
|
§ page.team.total.daysWorked.title: person-days
|
||||||
|
§ page.team.total.daysWorked.description: Only days with commits are counted
|
||||||
|
§ page.team.total.commits.title: commits
|
||||||
|
§ page.team.total.commits.description: Deleted branches are not counted
|
||||||
|
§ page.team.total.daysLosses.title: days without commits
|
||||||
|
§ page.team.total.daysLosses.description: All days minus: holidays, weekends, vacation, days with commits
|
||||||
|
§ page.team.total.employment.title: working / dismissed
|
||||||
|
§ page.team.total.employment.description: If an employee does not make any commits within a month, they are considered dismissed
|
||||||
|
§ page.team.total.moneyAll.title: total
|
||||||
|
§ page.team.total.moneyAll.description: Total salary expenses
|
||||||
|
§ page.team.total.moneyWorked.title: actual
|
||||||
|
§ page.team.total.moneyWorked.description: Actual days worked multiplied by average salary
|
||||||
|
§ page.team.total.moneyLosses.title: possible overpayment
|
||||||
|
§ page.team.total.moneyLosses.description: Paid working days when there were no commits
|
||||||
|
§ page.team.total.weekendPayment.title: weekend work
|
||||||
|
§ page.team.total.weekendPayment.description: Total overpayment for weekend work
|
||||||
|
§ page.team.total.workSpeed.title: tasks per day
|
||||||
|
§ page.team.total.workSpeed.description: Average work speed of the team with the current composition of employees
|
||||||
|
§ page.team.total.moneySpeed.title: per month
|
||||||
|
§ page.team.total.moneySpeed.description: Forecasted salary payment amount with the current team composition, excluding taxes and related expenses
|
||||||
|
§ page.team.total.description1: *Person-days* — the work of one employee during a single working day. For example, in one calendar day, a team of three employees produces a work volume of three person-days.
|
||||||
|
§ page.team.total.description2: *Absentee days* are counted only as working days when commits could have been made. Weekends, public holidays, and vacations are not included in the calculation.
|
||||||
|
§ page.team.total.description3: The *working and dismissed* card shows the actual composition of employees who are continuously involved in work. Additionally, there are "assistants" — typically employees of a different specialization who may occasionally make commits to the project.
|
||||||
|
§ page.team.total.description4: *Overpayment* includes only working days when commits could have been made. Weekends, public holidays, and vacations are not included in the calculation. This is why overpayment + actual cost != total. The total cost includes payment for weekends, public holidays, and vacations.
|
||||||
|
§ page.team.total.description5: *Weekend work* is calculated at a rate of x2 the payment of a regular day. The displayed amount is specifically the overpayment (x1), as the fact of overtime in this context is not of interest. We focus on overpayment when increasing work speed.
|
||||||
|
§ page.team.tree.title: Project Tree Considering Selected Filters
|
||||||
|
§ page.team.tree.filters.author: Employee
|
||||||
|
§ page.team.tree.filters.commits: Number of commits
|
||||||
|
§ page.team.tree.filters.help: The minimum number of commits an employee has made in a file
|
||||||
|
§ page.team.tree.filters.all: All employees
|
||||||
|
§ page.team.tree.add: Who added
|
||||||
|
§ page.team.tree.change: Who changed
|
||||||
|
§ page.team.tree.remove: Who removed
|
||||||
|
§ page.team.tree.line: lines
|
||||||
|
§ page.team.tree.lineAdd: added
|
||||||
|
§ page.team.tree.lineRemove: changed
|
||||||
|
§ page.team.week.title: Weekly statistics
|
||||||
|
§ page.team.week.date: Date
|
||||||
|
§ page.team.week.numberTasks: Number of tasks
|
||||||
|
§ page.team.week.people: Number of people
|
||||||
|
§ page.team.week.line: Line Changes
|
||||||
|
§ page.team.week.days: Days with and without commits
|
||||||
|
§ page.team.week.lossesDetails: Who did not commit
|
||||||
|
§ page.team.week.add: added
|
||||||
|
§ page.team.week.change: changed
|
||||||
|
§ page.team.week.remove: removed
|
||||||
|
§ page.team.week.hasCommits: had commits
|
||||||
|
§ page.team.week.hasNotCommits: had no commits
|
||||||
|
§ page.team.week.days: days
|
||||||
|
§ page.team.week.tasks: tasks
|
||||||
|
§ page.team.pr.task: Task
|
||||||
|
§ page.team.pr.tasks: tasks
|
||||||
|
§ page.team.pr.firstCommitTime: First commit
|
||||||
|
§ page.team.pr.lastCommitTime: Last
|
||||||
|
§ page.team.pr.workDays: Development days
|
||||||
|
§ page.team.pr.delayDays: Days waiting for merge
|
||||||
|
§ page.team.pr.commits: Commits
|
||||||
|
§ page.team.pr.date: Merge Date
|
||||||
|
§ page.team.pr.mergeAuthor: Merged by
|
||||||
|
§ page.team.pr.author: Employee
|
||||||
|
§ page.team.pr.middleTimeRelease: Average delivery time (days)
|
||||||
|
§ page.team.pr.work: development
|
||||||
|
§ page.team.pr.delay: waiting
|
||||||
|
§ page.team.pr.days: days
|
||||||
|
§ page.team.pr.oneTaskDays: Time spent on one task
|
||||||
|
§ page.team.pr.description1: *Development time* is the time difference from the first to the last commit on a task. It does not matter if there were breaks of several days between commits or not. Any commit increases the time.
|
||||||
|
§ page.team.pr.description2: *Waiting time* is the time between the last commit and the code merge. It shows the actual downtime while waiting for something.
|
||||||
|
§ page.team.pr.description3: *Why display development time* without splitting into coding and code review? To show the business the actual delivery time of the code. Waiting for testing, review comments, DevOps problems, and other process imperfections are already included in this term.
|
||||||
|
§ page.team.pr.statByAuthors: Statistics by employees
|
||||||
|
§ page.team.pr.longDelay: Prolonged Waiting for merge
|
||||||
|
§ page.team.tasks.task: Task
|
||||||
|
§ page.team.tasks.author: First commit author
|
||||||
|
§ page.team.tasks.from: First commit
|
||||||
|
§ page.team.tasks.to: Last commit
|
||||||
|
§ page.team.tasks.daysInWork: Days in work
|
||||||
|
§ page.team.tasks.commits: Commits number
|
||||||
|
§ page.team.tasks.pr: Merge date
|
||||||
|
§ page.team.tasks.prAuthor: Merged by user
|
||||||
|
§ page.team.tasks.prDelayDays: Delay before merge in days
|
||||||
|
§ page.team.tasks.comments: Comments
|
||||||
|
§ page.person.print.photo.title: Photo
|
||||||
|
§ page.person.print.photo.description: space for a photo
|
||||||
|
§ page.person.total.title: Main characteristics
|
||||||
|
§ page.person.total.daysWorked.title: days of work
|
||||||
|
§ page.person.total.daysWorked.description: Only days with commits are counted
|
||||||
|
§ page.person.total.tasks.title: tasks
|
||||||
|
§ page.person.total.tasks.description: If commits are properly signed
|
||||||
|
§ page.person.character.title: Character
|
||||||
|
§ page.person.achievement.title: Achievements
|
||||||
|
§ page.person.achievement.positive: Positive
|
||||||
|
§ page.person.achievement.normal: Neutral
|
||||||
|
§ page.person.achievement.negative: Negative
|
||||||
|
§ page.person.achievement.description: The more negative achievements an employee accumulates, the higher the likelihood that the situation is unusual. It may be necessary to change their work mode, tasks, or reporting. A discussion with them to understand what problems are hindering their work is advisable.
|
||||||
|
§ page.person.gets.title: Gets taken:
|
||||||
|
§ page.person.gets.description: "Taking a get" in this context means being the first to leave a commit on a task with a "nice" number.
|
||||||
|
§ page.person.business.days.title: days of work
|
||||||
|
§ page.person.business.days.description: Only days with commits are counted
|
||||||
|
§ page.person.business.tasks.title: tasks
|
||||||
|
§ page.person.business.tasks.description: If commits are properly signed
|
||||||
|
§ page.person.business.losses.title: days without commits
|
||||||
|
§ page.person.business.losses.description: All days minus: holidays, weekends, vacation, days with commits
|
||||||
|
§ page.person.business.commits.title: commits
|
||||||
|
§ page.person.business.commits.description: Deleted branches are not counted
|
||||||
|
§ page.person.business.time.description: Time from the first to the last commit (including non-working days)
|
||||||
|
§ page.person.business.time.title: Days on the project:
|
||||||
|
§ page.person.business.time.dismissed: (dismissed)
|
||||||
|
§ page.person.business.time.staff: (not in the team)
|
||||||
|
§ page.person.business.achievements: Achievements
|
||||||
|
§ page.person.changes.title: Achievements
|
||||||
|
§ page.person.changes.description:
|
||||||
|
With some types of formatting, git marks lines as "deleted" and "added",
|
||||||
|
although in reality, they were "changed". Therefore, if you conducted a major refactoring,
|
||||||
|
git might show a small number of changes in the statistics, but the actual result
|
||||||
|
will be marked as a jump in "deleted" and "added" lines.
|
||||||
|
§ page.person.changes.description: List of commits and the number of changes in them for that day:
|
||||||
|
§ page.person.commits.title: List of commits:
|
||||||
|
§ page.person.money.title.total: Total over time
|
||||||
|
§ page.person.money.title.middle: Average cost
|
||||||
|
§ page.person.money.moneyAll.title: received
|
||||||
|
§ page.person.money.moneyAll.description: Assumed total salary from the project (see settings)
|
||||||
|
§ page.person.money.moneyWorked.title: worked for
|
||||||
|
§ page.person.money.moneyWorked.description: Actual days worked multiplied by average salary
|
||||||
|
§ page.person.money.moneyLosses.title: possible overpayment
|
||||||
|
§ page.person.money.moneyLosses.description: Days without commits multiplied by average salary
|
||||||
|
§ page.person.money.tasks.title: task
|
||||||
|
§ page.person.money.tasks.description: Number of closed tasks to the cost of the day
|
||||||
|
§ page.person.money.commits.title: commit
|
||||||
|
§ page.person.money.commits.description: Number of commits to the cost of the workday
|
||||||
|
§ page.person.speed.task: One task on average is
|
||||||
|
§ page.person.speed.max: Maximum speed per day
|
||||||
|
§ page.person.speed.days.title: days
|
||||||
|
§ page.person.speed.days.description: Refers to workdays, if commits are properly signed
|
||||||
|
§ page.person.speed.commits.title: commits
|
||||||
|
§ page.person.speed.commits.description: Top and bottom 10% of values are trimmed
|
||||||
|
§ page.person.speed.line.title: lines of code
|
||||||
|
§ page.person.speed.line.description: Top and bottom 10% of values are trimmed
|
||||||
|
§ page.person.speed.tasks.title: tasks
|
||||||
|
§ page.person.speed.tasks.description: A task may not be completed, but work should be done on it
|
||||||
|
§ page.person.speed.maxCommits.title: commits
|
||||||
|
§ page.person.speed.maxCommits.description: A task may not be completed, but work should be done on it
|
||||||
|
§ page.person.hours.title: Distribution of commits during each day of the week
|
||||||
|
§ page.person.week.date: Date
|
||||||
|
§ page.person.week.tasks: Number of tasks
|
||||||
|
§ page.person.week.workDays: Days with commits
|
||||||
|
§ page.person.week.taskInDay: Tasks per day
|
||||||
|
§ page.person.week.days: days
|
||||||
|
§ page.person.week.workDay: weekdays
|
||||||
|
§ page.person.week.weekends: weekends
|
||||||
|
`;
|
504
src/ts/translations/ja/recommendations.ts
Normal file
504
src/ts/translations/ja/recommendations.ts
Normal file
|
@ -0,0 +1,504 @@
|
||||||
|
export default `
|
||||||
|
§ recommendations.modal.cancel: Ok
|
||||||
|
§ recommendations.title
|
||||||
|
Recommendations and Facts
|
||||||
|
|
||||||
|
§ recommendations.timestamp.firstCommit.description
|
||||||
|
made the first commit
|
||||||
|
|
||||||
|
Day of the Week: $1
|
||||||
|
|
||||||
|
§ recommendations.timestamp.lastCommit.description
|
||||||
|
made the last commit
|
||||||
|
|
||||||
|
Day of the Week: $1
|
||||||
|
|
||||||
|
§ recommendations.timestamp.common.title: $1 days
|
||||||
|
§ recommendations.timestamp.allDays.description: from the first to the last commit (including weekends and holidays).
|
||||||
|
§ recommendations.timestamp.lossesDays.description: days without commits, even considering weekends, vacation, and public holidays.
|
||||||
|
§ recommendations.timestamp.weekendDays.description
|
||||||
|
working on weekends
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- employees burn out faster;
|
||||||
|
|
||||||
|
§ recommendations.timestamp.regularWeekendWord.title: Regular Overtime
|
||||||
|
§ recommendations.timestamp.sometimeWeekendWord.title: Occasional Overtime
|
||||||
|
§ recommendations.timestamp.weekendWord.description
|
||||||
|
It might be advisable to change the project manager, analyst, and architect.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- the quality of the product is usually low;
|
||||||
|
- some employees resign;
|
||||||
|
- new errors emerge due to the rush;
|
||||||
|
|
||||||
|
# Most likely:
|
||||||
|
- deadlines were incorrectly estimated at the beginning;
|
||||||
|
- technical specifications are missing;
|
||||||
|
- weak analytics;
|
||||||
|
- weak architecture (no architect was hired, and the team consists of mid-level developers);
|
||||||
|
- started writing code first, then planning;
|
||||||
|
- lack of proper processes to understand mistakes;
|
||||||
|
|
||||||
|
§ recommendations.timestamp.neverWeekendWord.title: Usually Without Overtime
|
||||||
|
§ recommendations.timestamp.neverWeekendWord.description
|
||||||
|
But sometimes it happens.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- employees burn out faster;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.not.title
|
||||||
|
No Parallel Work
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.not.description
|
||||||
|
any feature at any given time is done by one person.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is less than 1.3, we consider that there is usually no parallel work within most features;
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- increases bus factor;
|
||||||
|
- employees develop more slowly;
|
||||||
|
- difficult to properly check an employee's work;
|
||||||
|
|
||||||
|
# Why this is good:
|
||||||
|
- experts emerge who are deeply immersed in the subject area and can offer more quality solutions;
|
||||||
|
- most likely there are no merge conflicts;
|
||||||
|
- the project can quickly develop in different directions simultaneously;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.has.title
|
||||||
|
Some Work Done in Parallel
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.has.description
|
||||||
|
Sometimes a feature is worked on simultaneously by several people.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is from 1.3 to 2.0, we consider that some of the work within different features is sometimes done in parallel;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.every.title
|
||||||
|
Parallel Work
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.every.description
|
||||||
|
any feature at any given time is worked on by several people
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is more than two, we consider that most of the work within different features is usually done in parallel;
|
||||||
|
|
||||||
|
§ recommendations.scope.money
|
||||||
|
this is the estimated cost for the work on this project.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days spent on development are multiplied by the individual salaries of the developers;
|
||||||
|
|
||||||
|
To change the salary of each developer for a more accurate total, go to the "Settings" section.
|
||||||
|
|
||||||
|
# Is this too much or too little?
|
||||||
|
To answer this question, consider the following:
|
||||||
|
- Could a ready-made solution have been purchased for this amount of money?
|
||||||
|
- Could a better product have been developed for this amount of money?
|
||||||
|
|
||||||
|
If the answer to both questions is "yes," then perhaps developing from scratch was not worth the money spent.
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.everyHasOne.title
|
||||||
|
Bus factor = 1
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.everyHasOne.description
|
||||||
|
Most features are deeply understood by only one person.
|
||||||
|
It's necessary to rotate people.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- if employees resign, it will be difficult to continue their work;
|
||||||
|
- it’s impossible to control the quality of their code;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- more than 80% of commits in a feature are made by one person;
|
||||||
|
- the project has more than 60% of such features;
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.oneMaintainer
|
||||||
|
one person is deeply involved in a feature.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- if they resign, it will be hard to continue development;
|
||||||
|
- the quality of code-review decreases;
|
||||||
|
- it’s difficult to parallelize development when needed;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- more than 80% of commits in a feature are made by one person;
|
||||||
|
|
||||||
|
§ recommendations.scope.types.process.title
|
||||||
|
Poor Processes
|
||||||
|
|
||||||
|
§ recommendations.scope.types.process.description
|
||||||
|
Most features contain one type of task.
|
||||||
|
|
||||||
|
§ recommendations.scope.types.one
|
||||||
|
features contain one type of task.
|
||||||
|
|
||||||
|
§ recommendations.scope.types.common
|
||||||
|
It's possible that developers are incorrectly signing commits or the manager is entering the same type of tasks.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- it's impossible to hand over support to another team;
|
||||||
|
- it's impossible to release a "boxed" version;
|
||||||
|
- strong dependence on specific developers;
|
||||||
|
- a high number of errors and low code quality;
|
||||||
|
- potential slowdown in development in the future;
|
||||||
|
|
||||||
|
# The manager's mistake:
|
||||||
|
- viewing the product only from the perspective of a "working demo";
|
||||||
|
|
||||||
|
# What should be done:
|
||||||
|
- tests;
|
||||||
|
- bugs (identified through testing);
|
||||||
|
- refactoring (as architecture may change);
|
||||||
|
- documentation;
|
||||||
|
- style revisions (as a result of focus group feedback);
|
||||||
|
|
||||||
|
§ recommendations.scope.plan.title
|
||||||
|
Develop a Long-Term Plan
|
||||||
|
|
||||||
|
§ recommendations.scope.plan.description
|
||||||
|
taking architecture into account.
|
||||||
|
|
||||||
|
This plan should immediately focus on the most challenging tasks.
|
||||||
|
|
||||||
|
# Why the lack of a plan is bad:
|
||||||
|
- employees create a minimally viable version without planning for expansion points. After this, unscalable code is written, which slows down future features;
|
||||||
|
|
||||||
|
# The manager's mistake:
|
||||||
|
- they haven't shown how the product will develop further and where the growth points will be;
|
||||||
|
|
||||||
|
# How it should be done:
|
||||||
|
- a global product development plan is created;
|
||||||
|
- a global architecture development plan is created (with developers and DBAs);
|
||||||
|
- potential significant changes are discussed upfront at the schematic level;
|
||||||
|
|
||||||
|
§ recommendations.scope.cost.title
|
||||||
|
Evaluate Investment in a Feature
|
||||||
|
|
||||||
|
§ recommendations.scope.cost.description
|
||||||
|
in terms of potential profit.
|
||||||
|
|
||||||
|
Features that are expensive to develop but bring little profit may need to be postponed or even canceled. This will make the project more commercially successful.
|
||||||
|
|
||||||
|
§ recommendations.author.lotOfLazy
|
||||||
|
writes too little code.
|
||||||
|
|
||||||
|
# Should they be fired?
|
||||||
|
- are they a team leader, architect, or analyst?
|
||||||
|
- is this their primary project?
|
||||||
|
- are there any dependencies on them?
|
||||||
|
|
||||||
|
# Why it makes no sense to correct
|
||||||
|
The total costs for the developer are already more than the profit from their work.
|
||||||
|
If we believe that there were no objective hindrances to their work, then the person either does not want to work at all or is working on two projects simultaneously.
|
||||||
|
Firing and replacing them with a new employee seems justified from a statistical point of view.
|
||||||
|
|
||||||
|
§ recommendations.author.manyLazy
|
||||||
|
writes little code. Needs to be monitored.
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- in test samples, a good programmer writes code for more than 80% of the time;
|
||||||
|
- in this case, the indicator is between 60% and 80%;
|
||||||
|
|
||||||
|
# How to monitor:
|
||||||
|
- break tasks into 1..2 days;
|
||||||
|
- ask for a status update every day;
|
||||||
|
- ensure tasks are well defined and ready for development;
|
||||||
|
- arrange pair programming to check actual speed;
|
||||||
|
|
||||||
|
§ recommendations.author.oneTypeMans
|
||||||
|
receives too many monotonous tasks of the same type. Risk of burnout.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- if an employee burns out, their work speed will decrease;
|
||||||
|
- professional growth slows down;
|
||||||
|
- the likelihood of resignation increases;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- the type of task is determined for each commit;
|
||||||
|
- if more than 70% of tasks are of the same type, it means the person is doing the same thing repeatedly;
|
||||||
|
|
||||||
|
§ recommendations.author.workToday.title: Working $1
|
||||||
|
§ recommendations.author.workToday.description
|
||||||
|
on the project at this moment.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- more than 50% of workdays;
|
||||||
|
- have worked during the last 30 days;
|
||||||
|
|
||||||
|
§ recommendations.author.dismissed.title: Dismissed $1
|
||||||
|
§ recommendations.author.dismissed.description
|
||||||
|
or worked for a short period.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- worked at a normal pace (apparently, this is their main repository);
|
||||||
|
- no commits in the last month;
|
||||||
|
- vacation usually lasts 14 days (their absence does not resemble a vacation);
|
||||||
|
|
||||||
|
§ recommendations.author.staff.title: Assisting $1
|
||||||
|
§ recommendations.author.staff.description
|
||||||
|
People of other specializations who have committed something.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- this is not an open-source project;
|
||||||
|
- workdays less than 15% of the total number;
|
||||||
|
- modify roughly the same files;
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.openSource.title
|
||||||
|
Open Project
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.openSource.description
|
||||||
|
they do not work five days a week here.
|
||||||
|
|
||||||
|
The project may be closed, but this work pace is typical for open libraries on GitHub.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- statistics are taken for all active developers;
|
||||||
|
- the average number of working days and days without commits is calculated;
|
||||||
|
- for open-source libraries, working days are usually a maximum of 15..20%;
|
||||||
|
|
||||||
|
# Consequences
|
||||||
|
For projects where work is not constant, many indicators do not make sense. Therefore, indicators like days without commits, speed, etc., will be hidden.
|
||||||
|
|
||||||
|
Typically, such projects are assessed before starting the development of their own closed version. The most interesting indicators in this case are the probable cost and total development time.
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.easy.title
|
||||||
|
Light Workload
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.easy.description
|
||||||
|
too many days without commits. It is necessary to understand why the team is not writing code.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- take statistics from all active developers;
|
||||||
|
- calculate the average number of working days and days without commits;
|
||||||
|
- workload is considered light if the percentage of days without commits is between 5% and 20%;
|
||||||
|
|
||||||
|
# Possible reasons:
|
||||||
|
- there are actually no tasks;
|
||||||
|
- there are tasks, but they fit well with the current architecture;
|
||||||
|
- developers are distracted by meetings;
|
||||||
|
- the team is not working;
|
||||||
|
|
||||||
|
# Solutions:
|
||||||
|
- discuss the issue with the team;
|
||||||
|
- reduce task granularity so that one or two tasks can be completed in a day;
|
||||||
|
- introduce daily meetings to check the status of tasks;
|
||||||
|
- arrange pair programming sessions to ensure that the developer can work faster;
|
||||||
|
|
||||||
|
§ recommendations.author.manager.title
|
||||||
|
Set Deadlines
|
||||||
|
|
||||||
|
§ recommendations.author.manager.description
|
||||||
|
Every task should have a clear deadline.
|
||||||
|
|
||||||
|
This will prevent dragging out its completion for several days or weeks.
|
||||||
|
|
||||||
|
# Indicators to check:
|
||||||
|
- the number of days spent on one task by an employee;
|
||||||
|
- the number of days waiting for PR merge (PR statistics page);
|
||||||
|
|
||||||
|
§ recommendations.author.shorTalk.title
|
||||||
|
Conduct Daily Meetings
|
||||||
|
|
||||||
|
§ recommendations.author.shorTalk.description
|
||||||
|
they help stay informed about the project.
|
||||||
|
|
||||||
|
Do not stretch them by getting sidetracked on irrelevant topics.
|
||||||
|
|
||||||
|
# Questions the employee should answer:
|
||||||
|
- what was done;
|
||||||
|
- what will be done;
|
||||||
|
- are there any issues;
|
||||||
|
|
||||||
|
# Interruptions should occur if:
|
||||||
|
- they start describing minor details in-depth, which are not important;
|
||||||
|
- they steer the conversation away from the original plan;
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
Often an employee who does nothing tries to avoid the answer by telling a bunch of unnecessary details of their work. This lulls the participants' attention and stretches the time for a response. It creates an impression that they are busy, even though there was no actual work done.
|
||||||
|
|
||||||
|
§ recommendations.author.ipr.title
|
||||||
|
Develop a Training Plan
|
||||||
|
|
||||||
|
§ recommendations.author.ipr.description
|
||||||
|
for each employee.
|
||||||
|
|
||||||
|
*Individual training plan* is a list of goals and tasks that help a person develop in a certain area.
|
||||||
|
|
||||||
|
# How to create a plan:
|
||||||
|
- create a competency matrix;
|
||||||
|
- identify which competencies have the least knowledge and experience;
|
||||||
|
- find out which of these competencies are of interest to the employee;
|
||||||
|
- come up with 3..5 goals within each such competency for the next six months or a year;
|
||||||
|
- try to do something every month to achieve one goal;
|
||||||
|
- remind every month about the overall plan to achieve these goals;
|
||||||
|
|
||||||
|
# Does a manager need a plan?
|
||||||
|
Yes, the manager should also make a plan for themselves. If there is no higher-level manager, they should self-assess.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- employees become more loyal to the company;
|
||||||
|
- you get more qualified personnel for the same money;
|
||||||
|
|
||||||
|
§ recommendations.author.oneToOne.title
|
||||||
|
Conduct One-on-One Meetings Every Month
|
||||||
|
|
||||||
|
§ recommendations.author.oneToOne.description
|
||||||
|
it helps to identify problems at an early stage.
|
||||||
|
|
||||||
|
*One-to-one* is a regular personal meeting of a manager with a subordinate. Such meetings typically discuss everything important to the employee, what concerns them, and what they can share with the manager in private.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- easy to find out who is overburdened and who has free time;
|
||||||
|
- possible to prevent employee burnout;
|
||||||
|
- quick feedback can be obtained about processes that you might not notice;
|
||||||
|
- trust is built, making employees more loyal to the company;
|
||||||
|
- increases employee motivation and engagement;
|
||||||
|
|
||||||
|
§ recommendations.author.club.title
|
||||||
|
Go to a Bar
|
||||||
|
|
||||||
|
§ recommendations.author.club.description
|
||||||
|
once a month or two.
|
||||||
|
|
||||||
|
This will help build informal communication within the team and bring the team together, even if the interaction is brief.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- quick feedback can be obtained about processes that you might not notice;
|
||||||
|
- trust is built, making employees more loyal to the company;
|
||||||
|
- increases employee engagement;
|
||||||
|
|
||||||
|
§ recommendations.hour.onlyWork.title: No Weekends Here
|
||||||
|
§ recommendations.hour.onlyWork.description: The project manager should probably be fired.
|
||||||
|
§ recommendations.hour.weekends.title: Working on Weekends
|
||||||
|
§ recommendations.hour.weekends.description: The project manager should probably be checked.
|
||||||
|
§ recommendations.hour.easy.title: There Are Problems
|
||||||
|
§ recommendations.hour.easy.description: There are likely crunch times and work is needed on weekends.
|
||||||
|
§ recommendations.week.lazyDays.down.title: Fewer Absences
|
||||||
|
§ recommendations.week.lazyDays.down.description: this indicator has dropped over the last three weeks
|
||||||
|
§ recommendations.week.lazyDays.up.title: More Absences
|
||||||
|
§ recommendations.week.lazyDays.up.description: no tasks or stricter control is needed
|
||||||
|
§ recommendations.week.notWork.title: Consistently Underperforms
|
||||||
|
§ recommendations.week.notWork.description: as every week the code is not 100% of the time
|
||||||
|
§ recommendations.week.upWork.title: Consistently Overworks
|
||||||
|
§ recommendations.week.upWork.description: as every week code is written on weekend days
|
||||||
|
§ recommendations.week.task.up.title: Productivity is growing
|
||||||
|
§ recommendations.week.task.up.description: or tasks have become too small. Need to check. If granularity is the same - reinforce the result.
|
||||||
|
§ recommendations.week.task.lazyMaintainer.description: consistently leads in absences. Fire?
|
||||||
|
§ recommendations.week.task.down.title: Productivity is Falling
|
||||||
|
§ recommendations.week.task.down.description
|
||||||
|
or tasks are poorly split. Need to check. If granularity is the same - take control.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- the number of tasks per day that are being worked on has been steadily decreasing over the last three weeks.
|
||||||
|
|
||||||
|
# Possible errors:
|
||||||
|
- tasks could have been more complex than they seemed;
|
||||||
|
- tasks could have had a large volume of work (need to check if the number of changes is also decreasing during this period)
|
||||||
|
|
||||||
|
§ recommendations.type.everyHasOne.title: Not Signing Task Types
|
||||||
|
§ recommendations.type.everyHasOne.description: Most task types are done by one person.
|
||||||
|
§ recommendations.type.oneMaintainer.title: Narrow Specialization
|
||||||
|
§ recommendations.type.oneMaintainer.description
|
||||||
|
most tasks of one type are done by the same people.
|
||||||
|
|
||||||
|
# Task types:
|
||||||
|
|
||||||
|
§ recommendations.type.common
|
||||||
|
# It might not be the case
|
||||||
|
|
||||||
|
Make sure that other employees correctly sign commits.
|
||||||
|
|
||||||
|
Steps to ensure this:
|
||||||
|
- set up a pre-commit check for commit messages;
|
||||||
|
- explain to the team the need to indicate the type;
|
||||||
|
- check in new branches that employees follow this rule;
|
||||||
|
|
||||||
|
# If it is indeed the case
|
||||||
|
|
||||||
|
You have set up checks and ensured that the same employee does tasks of the same type.
|
||||||
|
|
||||||
|
Why this is bad:
|
||||||
|
- their resignation will halt a whole bunch of processes;
|
||||||
|
- it reduces the competence of other team members;
|
||||||
|
- difficult to understand their edits at a higher level;
|
||||||
|
|
||||||
|
How to fix this:
|
||||||
|
- distribute different types of tasks evenly;
|
||||||
|
- change the area of work (tests, documentation, bugs) among employees every sprint;
|
||||||
|
|
||||||
|
§ recommendations.type.fewTypes.title
|
||||||
|
This is a Local Product
|
||||||
|
|
||||||
|
§ recommendations.type.fewTypes.description
|
||||||
|
for a specific customer or problem.
|
||||||
|
|
||||||
|
# Signs of a "global" product:
|
||||||
|
- localization;
|
||||||
|
- documentation;
|
||||||
|
- a large volume of tests;
|
||||||
|
- visual customization;
|
||||||
|
- refactoring of bottlenecks;
|
||||||
|
- etc.
|
||||||
|
|
||||||
|
# Why this product looks like a "local" one:
|
||||||
|
- each "global" sign will be outweighed by its type of task;
|
||||||
|
- the more "global" signs, the more likely a "global" product;
|
||||||
|
|
||||||
|
In this case, we see a small number of types, which likely indicates shortcomings that prevent the product from being easily scaled to the global market and sold in other countries.
|
||||||
|
|
||||||
|
# It might not be the case
|
||||||
|
Based on file types, we can assume the type of program (website, server application, DevOps scripts, etc.). For a frontend application, our hypothesis will be more accurate than for DevOps scripts, which might just be a micro-module of initialization.
|
||||||
|
|
||||||
|
§ recommendations.type.diff.title
|
||||||
|
Break Down the Leading Type into Subtypes
|
||||||
|
|
||||||
|
§ recommendations.type.diff.description
|
||||||
|
to detail errors.
|
||||||
|
|
||||||
|
Typically, the task type labeled "bug fixing" is leading. This makes the statistics weakly detailed.
|
||||||
|
|
||||||
|
*If you encounter this situation*, you can break down this type into subtypes (e.g., based on the location of detection).
|
||||||
|
|
||||||
|
Consider several options for subtypes:
|
||||||
|
- fix_dev (error detected during development);
|
||||||
|
- fix_test (error detected during testing);
|
||||||
|
- fix (error detected in production);
|
||||||
|
|
||||||
|
§ recommendations.type.buddy.title
|
||||||
|
Accumulate Minor Tasks
|
||||||
|
|
||||||
|
§ recommendations.type.buddy.description
|
||||||
|
for new employees.
|
||||||
|
|
||||||
|
# If a task is:
|
||||||
|
- not important;
|
||||||
|
- not big;
|
||||||
|
- doesn't require deep immersion in the context;
|
||||||
|
- more about refactoring than new code;
|
||||||
|
|
||||||
|
# Put it in the backlog with the label "for beginners".
|
||||||
|
|
||||||
|
When a new employee arrives, you will be able to immediately pull out a bunch of small and varied tasks for them to get acquainted with the project.
|
||||||
|
|
||||||
|
Also, if you have a lull in work, you can pull out one such minor task from the backlog.
|
||||||
|
`;
|
27
src/ts/translations/ja/settings.ts
Normal file
27
src/ts/translations/ja/settings.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ page.settings.document.title: Display settings
|
||||||
|
§ page.settings.document.name: Page title
|
||||||
|
§ page.settings.document.language: Interface language
|
||||||
|
§ page.settings.links.title: Link prefixes
|
||||||
|
§ page.settings.links.task: For task numbers
|
||||||
|
§ page.settings.links.pr: For PR
|
||||||
|
§ page.settings.user.title: Individual settings
|
||||||
|
§ page.settings.user.notFound: No individual settings. Data for all employees are calculated based on common parameters.
|
||||||
|
§ page.settings.user.subTitle: Addendum to employment contract №$1
|
||||||
|
§ page.settings.user.from: Start date
|
||||||
|
§ page.settings.mailmap: .mailmap example
|
||||||
|
§ page.settings.common.title: General salary data
|
||||||
|
§ page.settings.common.type.title: Project work type
|
||||||
|
§ page.settings.common.type.full: Full-time employment
|
||||||
|
§ page.settings.common.type.part: Project work
|
||||||
|
§ page.settings.common.salary: Monthly salary
|
||||||
|
§ page.settings.common.currency: Currency
|
||||||
|
§ page.settings.common.workDaysInYear: Number of working days in a year
|
||||||
|
§ page.settings.common.vacationDaysInYear: Number of vacation days in a year
|
||||||
|
§ page.settings.common.workDaysInWeek: Workdays
|
||||||
|
§ page.settings.form.save: Save
|
||||||
|
§ page.settings.form.cancel: Cancel
|
||||||
|
§ page.settings.form.remove: Remove
|
||||||
|
§ page.settings.form.addEmployee: Add an employee
|
||||||
|
§ page.settings.form.addContract: Add an employment contract
|
||||||
|
`;
|
92
src/ts/translations/pt/achievements.ts
Normal file
92
src/ts/translations/pt/achievements.ts
Normal file
|
@ -0,0 +1,92 @@
|
||||||
|
export default `
|
||||||
|
§ achievements.commitsAfter1500.title: Owl
|
||||||
|
§ achievements.commitsAfter1500.description: 70% of commits after 3:00 PM
|
||||||
|
§ achievements.commitsBefore1500.title: Early bird
|
||||||
|
§ achievements.commitsBefore1500.description: 70% of commits before noon
|
||||||
|
§ achievements.workEveryTime.title: Devoted worker
|
||||||
|
§ achievements.workEveryTime.description: a commit for every hour of the day
|
||||||
|
§ achievements.workNotWork.title: Shooting blanks
|
||||||
|
§ achievements.workNotWork.description: commits are there, but no tasks are closed
|
||||||
|
§ achievements.userNotWork.title: Fly-by
|
||||||
|
§ achievements.userNotWork.description: this is not their main project
|
||||||
|
§ achievements.userIsDied.title: Dead soul
|
||||||
|
§ achievements.userIsDied.description: worked, but resigned
|
||||||
|
§ achievements.lessTasks.title: Came and went
|
||||||
|
§ achievements.lessTasks.description: least closed tasks
|
||||||
|
§ achievements.moreTasks.title: Father says well done
|
||||||
|
§ achievements.moreTasks.description: most closed tasks
|
||||||
|
§ achievements.everyMessageLong.title: Master of eloquence
|
||||||
|
§ achievements.everyMessageLong.description: consistently the longest commit messages
|
||||||
|
§ achievements.everyMessageShort.title: Talkative, a spy's dream
|
||||||
|
§ achievements.everyMessageShort.description: consistently, the shortest commit messages
|
||||||
|
§ achievements.shortestName.title: Size doesn't matter
|
||||||
|
§ achievements.shortestName.description: shortest name
|
||||||
|
§ achievements.longestName.title: Azim Aziz Il Am Kadir Imran II
|
||||||
|
§ achievements.longestName.description: longest name
|
||||||
|
§ achievements.moreCommits.title: Backup master
|
||||||
|
§ achievements.moreCommits.description: most commits
|
||||||
|
§ achievements.lessCommits.title: Rare but Precise
|
||||||
|
§ achievements.lessCommits.description: least commits
|
||||||
|
§ achievements.oneCommitOneTask.title: Right on target
|
||||||
|
§ achievements.oneCommitOneTask.description: on average one commit per task
|
||||||
|
§ achievements.moreLazyDays.title: With you in spirit
|
||||||
|
§ achievements.moreLazyDays.description: most days without commits
|
||||||
|
§ achievements.lessLazyDays.title: Papa carlo
|
||||||
|
§ achievements.lessLazyDays.description: least days without commits
|
||||||
|
§ achievements.zeroLazyDays.title: Not a single break
|
||||||
|
§ achievements.zeroLazyDays.description: not a single day without commits
|
||||||
|
§ achievements.moreWorkDays.title: Valuable employee
|
||||||
|
§ achievements.moreWorkDays.description: most working days
|
||||||
|
§ achievements.moreScopes.title: Startuper
|
||||||
|
§ achievements.moreScopes.description: completed the most features
|
||||||
|
§ achievements.lessScopes.title: Dandy
|
||||||
|
§ achievements.lessScopes.description: completed the fewest features
|
||||||
|
§ achievements.moreDaysForTask.title: Snail on the slope
|
||||||
|
§ achievements.moreDaysForTask.description: tasks take longer than others
|
||||||
|
§ achievements.more2DaysForTask.title: Slow and steady
|
||||||
|
§ achievements.more2DaysForTask.description: more than two days per task
|
||||||
|
§ achievements.moreDaysInProject.title: Old-timer
|
||||||
|
§ achievements.moreDaysInProject.description: most days in the project
|
||||||
|
§ achievements.lessDaysInProject.title: And who is this?
|
||||||
|
§ achievements.lessDaysInProject.description: least days in the project
|
||||||
|
§ achievements.more90DaysInProject.title: Welcome aboard
|
||||||
|
§ achievements.more90DaysInProject.description: not fired during the probation period
|
||||||
|
§ achievements.lessDaysForTask.title: Quick draw
|
||||||
|
§ achievements.lessDaysForTask.description: a task takes less than a day
|
||||||
|
§ achievements.adam.title: Adam
|
||||||
|
§ achievements.adam.description: the first stable employee on the project
|
||||||
|
§ achievements.more666DaysInProject.title: Devil
|
||||||
|
§ achievements.more666DaysInProject.description: worked 666 days on the project
|
||||||
|
§ achievements.more777DaysInProject.title: Azino three axes
|
||||||
|
§ achievements.more777DaysInProject.description: worked 777 days on the project
|
||||||
|
§ achievements.moreRefactoring.title: Executive editor
|
||||||
|
§ achievements.moreRefactoring.description: made the most 'refactoring' tags
|
||||||
|
§ achievements.longestMessage.title: So many conversations...
|
||||||
|
§ achievements.longestMessage.description: the longest commit message of all time
|
||||||
|
§ achievements.moreTasksInDay.title: Speed racer
|
||||||
|
§ achievements.moreTasksInDay.description: record for the number of tasks closed in a day
|
||||||
|
§ achievements.hasCommitFrom0to7.title: Night watch
|
||||||
|
§ achievements.hasCommitFrom0to7.description: a commit for every hour of the night
|
||||||
|
§ achievements.noCommitOnDay.title: Technical break
|
||||||
|
§ achievements.noCommitOnDay.description: there is a certain hour and day in working time when never commits
|
||||||
|
§ achievements.hasCommitEveryTime.title: Died at work
|
||||||
|
§ achievements.hasCommitEveryTime.description: a commit for every hour of each day (including weekends)
|
||||||
|
§ achievements.commitsAfter1800.title: Business Time
|
||||||
|
§ achievements.commitsAfter1800.description: no commits after 6:00 PM
|
||||||
|
§ achievements.more1488DaysInProject.title: Named after Maxim Martsinkevich
|
||||||
|
§ achievements.more1488DaysInProject.description: worked 1488 days on the project
|
||||||
|
§ achievements.moreFix.title: Bug hunter
|
||||||
|
§ achievements.moreFix.description: most closed bugs
|
||||||
|
§ achievements.lessWorkDays.title: Count me out
|
||||||
|
§ achievements.lessWorkDays.description: least working days
|
||||||
|
§ achievements.moreCreateCode.title: Creator
|
||||||
|
§ achievements.moreCreateCode.description: tends to add code more than others
|
||||||
|
§ achievements.moreRemoveCode.title: Destroyer
|
||||||
|
§ achievements.moreRemoveCode.description: tends to remove code more than others
|
||||||
|
§ achievements.moreChangeCode.title: Reformer
|
||||||
|
§ achievements.moreChangeCode.description: tends to change code more than others
|
||||||
|
§ achievements.moreStyle.title: Fashion police
|
||||||
|
§ achievements.moreStyle.description: tends to change CSS more than others
|
||||||
|
§ achievements.moreOnHoliday.title: No life
|
||||||
|
§ achievements.moreOnHoliday.description: relatively many commits in non-working hours
|
||||||
|
`;
|
27
src/ts/translations/pt/common.ts
Normal file
27
src/ts/translations/pt/common.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ uiKit.console.button: Copiar
|
||||||
|
§ uiKit.console.notification: Texto copiado
|
||||||
|
§ uiKit.dataLoader.page: Página
|
||||||
|
§ uiKit.dataLoader.size: Exibido por
|
||||||
|
§ uiKit.dataLoader.from: de
|
||||||
|
§ uiKit.dataLoader.all: Mostrar tudo
|
||||||
|
§ uiKit.hoursChart.work: Tempo de trabalho padrão. (dias de semana, das 07: 00 às 20:00)
|
||||||
|
§ uiKit.hoursChart.weekend: fins de semana ou tempo antes / depois do dia de trabalho
|
||||||
|
§ uiKit.hoursChart.days: número total de commits em um determinado dia e hora
|
||||||
|
§ uiKit.page.remove: Remover
|
||||||
|
§ uiKit.nothingFound.common.title: Não há ou não há dados suficientes para exibir
|
||||||
|
§ uiKit.nothingFound.common.description: O sistema processará mais dados se os commits forem assinados no formato [Git commit message convention|https://www.conventionalcommits.org/en/v1.0.0/]. Modelo:
|
||||||
|
§ uiKit.nothingFound.common.console: Número da tarefa_tipo(módulo): explicação
|
||||||
|
§ uiKit.nothingFound.common.example: Por exemplo:
|
||||||
|
§ uiKit.nothingFound.staff.title: Não há dados para este funcionário
|
||||||
|
§ uiKit.nothingFound.staff.description1:
|
||||||
|
Ele não fazia alterações todos os dias de trabalho. Por isso, ele recebeu o status “Assistente”.
|
||||||
|
As estatísticas de um trabalhador com esse status não precisam ser registradas. Sua influência é insignificante.
|
||||||
|
§ uiKit.nothingFound.staff.description2:
|
||||||
|
O sistema não calcula uma série de indicadores para ele.
|
||||||
|
Se este for um erro e a estatística para esse funcionário precisar ser levada em consideração, vá para a seção “Configurações” e altere o seu tipo.
|
||||||
|
§ common.title: Git estatística
|
||||||
|
§ common.filters: Filtro
|
||||||
|
§ common.notifications.save: Alterações salvas
|
||||||
|
§ common.notifications.setting: Configuração guardada
|
||||||
|
`;
|
15
src/ts/translations/pt/index.ts
Normal file
15
src/ts/translations/pt/index.ts
Normal file
|
@ -0,0 +1,15 @@
|
||||||
|
import achievements from './achievements';
|
||||||
|
import common from './common';
|
||||||
|
import navigation from './navigation';
|
||||||
|
import recommendations from './recommendations';
|
||||||
|
import settings from './settings';
|
||||||
|
import pages from './pages';
|
||||||
|
|
||||||
|
export default [
|
||||||
|
achievements,
|
||||||
|
common,
|
||||||
|
navigation,
|
||||||
|
recommendations,
|
||||||
|
settings,
|
||||||
|
pages,
|
||||||
|
].join('');
|
40
src/ts/translations/pt/navigation.ts
Normal file
40
src/ts/translations/pt/navigation.ts
Normal file
|
@ -0,0 +1,40 @@
|
||||||
|
export default `
|
||||||
|
§ sidebar.switch.team: Comando
|
||||||
|
§ sidebar.switch.person: Funcionário
|
||||||
|
§ sidebar.buttons.settings: Sintonização
|
||||||
|
§ sidebar.buttons.print: Impressão
|
||||||
|
§ sidebar.filters.all: o tempo todo
|
||||||
|
§ sidebar.filters.year: ano
|
||||||
|
§ sidebar.filters.halfYear: meio ano
|
||||||
|
§ sidebar.filters.month: mês
|
||||||
|
§ sidebar.filters.week: semana
|
||||||
|
§ sidebar.team.total: Informação geral
|
||||||
|
§ sidebar.team.scope: módulo
|
||||||
|
§ sidebar.team.author: Funcionário
|
||||||
|
§ sidebar.team.type: Tipos de Tarefas
|
||||||
|
§ sidebar.team.pr: Introdução do Código
|
||||||
|
§ sidebar.team.day: Por dia
|
||||||
|
§ sidebar.team.week: Por semana
|
||||||
|
§ sidebar.team.month: Por mês
|
||||||
|
§ sidebar.team.tree: Análise de arquivos
|
||||||
|
§ sidebar.team.files: Ficheiros
|
||||||
|
§ sidebar.team.removedFiles: Arquivos excluídos
|
||||||
|
§ sidebar.team.tasks: Lista de Tarefas
|
||||||
|
§ sidebar.team.hours: Horário
|
||||||
|
§ sidebar.team.commits: All commits
|
||||||
|
§ sidebar.team.changes: Todas as alterações
|
||||||
|
§ sidebar.team.words: Palavras populares
|
||||||
|
§ sidebar.team.top: Concurso
|
||||||
|
§ sidebar.team.settings: Sintonização
|
||||||
|
§ sidebar.person.total: Informação geral
|
||||||
|
§ sidebar.person.money: Custo do trabalho
|
||||||
|
§ sidebar.person.speed: Velocidade
|
||||||
|
§ sidebar.person.day: Por dia
|
||||||
|
§ sidebar.person.week: Por semana
|
||||||
|
§ sidebar.person.month: Por mês
|
||||||
|
§ sidebar.person.hours: Horário
|
||||||
|
§ sidebar.person.commits: All commits
|
||||||
|
§ sidebar.person.changes: Todas as alterações
|
||||||
|
§ sidebar.person.words: Palavras populares
|
||||||
|
§ sidebar.person.settings: Sintonização
|
||||||
|
`;
|
212
src/ts/translations/pt/pages.ts
Normal file
212
src/ts/translations/pt/pages.ts
Normal file
|
@ -0,0 +1,212 @@
|
||||||
|
export default `
|
||||||
|
§ page.welcome.step1: Execute the command in the root of your project.
|
||||||
|
§ page.welcome.step3: Drag and drop
|
||||||
|
§ page.welcome.step4: the log.txt file onto this page.
|
||||||
|
§ page.welcome.description: Git will create a log.txt file. It contains data for report generation. Or use git shortlog -s -n -e if you don't need a report. Create a [.mailmap|https://git-scm.com/docs/gitmailmap] file in the root of the project to consolidate employee statistics.
|
||||||
|
§ page.welcome.warning1: The service *DOES NOT SAVE* and *DOES NOT TRANSFER* your data. All calculations are performed locally in your browser on your machine.
|
||||||
|
§ page.welcome.warning2: The service *DOES NOT COLLECT STATISTICS* on projects. You can disconnect the internet, check traffic, and even build a local version from the [source|https://github.com/bakhirev/assayo].
|
||||||
|
§ page.common.words.title: Word Statistics.
|
||||||
|
§ page.common.words.description: the most popular word. Occurs $1 times.
|
||||||
|
§ page.common.commits.title: Number of commits by days.
|
||||||
|
§ page.common.commits.description: ($1) the most productive day in terms of the number of commits.
|
||||||
|
§ page.common.commits.title2: $1 commits made: $2
|
||||||
|
§ page.common.filter.allUsers: Does not matter
|
||||||
|
§ page.print.modal.title: What are we printing?
|
||||||
|
§ page.print.modal.page: Current page
|
||||||
|
§ page.print.modal.type: Current section
|
||||||
|
§ page.print.modal.all: All statistics
|
||||||
|
§ page.print.modal.cancel: Cancel
|
||||||
|
§ page.print.tableOfContents: Table of contents
|
||||||
|
§ page.print.title: Git repository report
|
||||||
|
§ page.print.sub_title: «$1»
|
||||||
|
§ page.print.description: The data for the report was obtained from the commit history.
|
||||||
|
§ page.team.author.title: Employee statistics
|
||||||
|
§ page.team.author.description1: *Part of the statistics* (work speed, costs, etc.) *for employees with the 'Assistant' type is not counted*, as it is an episodic role in the project. It is assumed that they do not affect the project, and their edits can be disregarded in the context of the overall volume of work.
|
||||||
|
§ page.team.author.description2: *Default sorting* is by the number of tasks and groups (current, fired, assisting employees).
|
||||||
|
§ page.team.author.types: Types of work
|
||||||
|
§ page.team.author.commits: Commits
|
||||||
|
§ page.team.author.commitsSmall: commits
|
||||||
|
§ page.team.author.tasks: Tasks
|
||||||
|
§ page.team.author.tasksSmall: tasks
|
||||||
|
§ page.team.author.workedLosses: Days with and without commits
|
||||||
|
§ page.team.author.worked: work
|
||||||
|
§ page.team.author.losses: days without commits
|
||||||
|
§ page.team.author.days: days
|
||||||
|
§ page.team.author.daysForTask: Days per task
|
||||||
|
§ page.team.author.scopes: Features
|
||||||
|
§ page.team.author.moneyAll: Received
|
||||||
|
§ page.team.author.moneyWorked: Worked for
|
||||||
|
§ page.team.author.moneyLosses: Overpayment
|
||||||
|
§ page.team.hours.title: Distribution of commits during each day of the week
|
||||||
|
§ page.team.month.title: Project work calendar
|
||||||
|
§ page.team.scope.title: Feature statistics
|
||||||
|
§ page.team.scope.scope: Feature
|
||||||
|
§ page.team.scope.days: Working Days
|
||||||
|
§ page.team.scope.authorsDays: Person-Days
|
||||||
|
§ page.team.scope.tasks: Tasks
|
||||||
|
§ page.team.scope.commits: Commits
|
||||||
|
§ page.team.scope.commitsSmall: commits
|
||||||
|
§ page.team.scope.types: Types of work
|
||||||
|
§ page.team.scope.authors: Personal contribution
|
||||||
|
§ page.team.scope.cost: Cost
|
||||||
|
§ page.team.type.title: Task type statistics
|
||||||
|
§ page.team.type.description: *Personal contribution* is counted by the number of commits, not the volume of changed lines or files. Therefore, the "File Analysis" section should also be consulted to assess the scale of changes.
|
||||||
|
§ page.team.type.type: Type of work
|
||||||
|
§ page.team.type.tasks: Tasks
|
||||||
|
§ page.team.type.tasksSmall: tasks
|
||||||
|
§ page.team.type.days: Days
|
||||||
|
§ page.team.type.daysSmall: days
|
||||||
|
§ page.team.type.authorsDays: Person-days
|
||||||
|
§ page.team.type.commits: Commits
|
||||||
|
§ page.team.type.authors: Personal contribution
|
||||||
|
§ page.team.total.titleA: Volume of work
|
||||||
|
§ page.team.total.titleB: Cost
|
||||||
|
§ page.team.total.daysWorked.title: person-days
|
||||||
|
§ page.team.total.daysWorked.description: Only days with commits are counted
|
||||||
|
§ page.team.total.commits.title: commits
|
||||||
|
§ page.team.total.commits.description: Deleted branches are not counted
|
||||||
|
§ page.team.total.daysLosses.title: days without commits
|
||||||
|
§ page.team.total.daysLosses.description: All days minus: holidays, weekends, vacation, days with commits
|
||||||
|
§ page.team.total.employment.title: working / dismissed
|
||||||
|
§ page.team.total.employment.description: If an employee does not make any commits within a month, they are considered dismissed
|
||||||
|
§ page.team.total.moneyAll.title: total
|
||||||
|
§ page.team.total.moneyAll.description: Total salary expenses
|
||||||
|
§ page.team.total.moneyWorked.title: actual
|
||||||
|
§ page.team.total.moneyWorked.description: Actual days worked multiplied by average salary
|
||||||
|
§ page.team.total.moneyLosses.title: possible overpayment
|
||||||
|
§ page.team.total.moneyLosses.description: Paid working days when there were no commits
|
||||||
|
§ page.team.total.weekendPayment.title: weekend work
|
||||||
|
§ page.team.total.weekendPayment.description: Total overpayment for weekend work
|
||||||
|
§ page.team.total.workSpeed.title: tasks per day
|
||||||
|
§ page.team.total.workSpeed.description: Average work speed of the team with the current composition of employees
|
||||||
|
§ page.team.total.moneySpeed.title: per month
|
||||||
|
§ page.team.total.moneySpeed.description: Forecasted salary payment amount with the current team composition, excluding taxes and related expenses
|
||||||
|
§ page.team.total.description1: *Person-days* — the work of one employee during a single working day. For example, in one calendar day, a team of three employees produces a work volume of three person-days.
|
||||||
|
§ page.team.total.description2: *Absentee days* are counted only as working days when commits could have been made. Weekends, public holidays, and vacations are not included in the calculation.
|
||||||
|
§ page.team.total.description3: The *working and dismissed* card shows the actual composition of employees who are continuously involved in work. Additionally, there are "assistants" — typically employees of a different specialization who may occasionally make commits to the project.
|
||||||
|
§ page.team.total.description4: *Overpayment* includes only working days when commits could have been made. Weekends, public holidays, and vacations are not included in the calculation. This is why overpayment + actual cost != total. The total cost includes payment for weekends, public holidays, and vacations.
|
||||||
|
§ page.team.total.description5: *Weekend work* is calculated at a rate of x2 the payment of a regular day. The displayed amount is specifically the overpayment (x1), as the fact of overtime in this context is not of interest. We focus on overpayment when increasing work speed.
|
||||||
|
§ page.team.tree.title: Project Tree Considering Selected Filters
|
||||||
|
§ page.team.tree.filters.author: Employee
|
||||||
|
§ page.team.tree.filters.commits: Number of commits
|
||||||
|
§ page.team.tree.filters.help: The minimum number of commits an employee has made in a file
|
||||||
|
§ page.team.tree.filters.all: All employees
|
||||||
|
§ page.team.tree.add: Who added
|
||||||
|
§ page.team.tree.change: Who changed
|
||||||
|
§ page.team.tree.remove: Who removed
|
||||||
|
§ page.team.tree.line: lines
|
||||||
|
§ page.team.tree.lineAdd: added
|
||||||
|
§ page.team.tree.lineRemove: changed
|
||||||
|
§ page.team.week.title: Weekly statistics
|
||||||
|
§ page.team.week.date: Date
|
||||||
|
§ page.team.week.numberTasks: Number of tasks
|
||||||
|
§ page.team.week.people: Number of people
|
||||||
|
§ page.team.week.line: Line Changes
|
||||||
|
§ page.team.week.days: Days with and without commits
|
||||||
|
§ page.team.week.lossesDetails: Who did not commit
|
||||||
|
§ page.team.week.add: added
|
||||||
|
§ page.team.week.change: changed
|
||||||
|
§ page.team.week.remove: removed
|
||||||
|
§ page.team.week.hasCommits: had commits
|
||||||
|
§ page.team.week.hasNotCommits: had no commits
|
||||||
|
§ page.team.week.days: days
|
||||||
|
§ page.team.week.tasks: tasks
|
||||||
|
§ page.team.pr.task: Task
|
||||||
|
§ page.team.pr.tasks: tasks
|
||||||
|
§ page.team.pr.firstCommitTime: First commit
|
||||||
|
§ page.team.pr.lastCommitTime: Last
|
||||||
|
§ page.team.pr.workDays: Development days
|
||||||
|
§ page.team.pr.delayDays: Days waiting for merge
|
||||||
|
§ page.team.pr.commits: Commits
|
||||||
|
§ page.team.pr.date: Merge Date
|
||||||
|
§ page.team.pr.mergeAuthor: Merged by
|
||||||
|
§ page.team.pr.author: Employee
|
||||||
|
§ page.team.pr.middleTimeRelease: Average delivery time (days)
|
||||||
|
§ page.team.pr.work: development
|
||||||
|
§ page.team.pr.delay: waiting
|
||||||
|
§ page.team.pr.days: days
|
||||||
|
§ page.team.pr.oneTaskDays: Time spent on one task
|
||||||
|
§ page.team.pr.description1: *Development time* is the time difference from the first to the last commit on a task. It does not matter if there were breaks of several days between commits or not. Any commit increases the time.
|
||||||
|
§ page.team.pr.description2: *Waiting time* is the time between the last commit and the code merge. It shows the actual downtime while waiting for something.
|
||||||
|
§ page.team.pr.description3: *Why display development time* without splitting into coding and code review? To show the business the actual delivery time of the code. Waiting for testing, review comments, DevOps problems, and other process imperfections are already included in this term.
|
||||||
|
§ page.team.pr.statByAuthors: Statistics by employees
|
||||||
|
§ page.team.pr.longDelay: Prolonged Waiting for merge
|
||||||
|
§ page.team.tasks.task: Task
|
||||||
|
§ page.team.tasks.author: First commit author
|
||||||
|
§ page.team.tasks.from: First commit
|
||||||
|
§ page.team.tasks.to: Last commit
|
||||||
|
§ page.team.tasks.daysInWork: Days in work
|
||||||
|
§ page.team.tasks.commits: Commits number
|
||||||
|
§ page.team.tasks.pr: Merge date
|
||||||
|
§ page.team.tasks.prAuthor: Merged by user
|
||||||
|
§ page.team.tasks.prDelayDays: Delay before merge in days
|
||||||
|
§ page.team.tasks.comments: Comments
|
||||||
|
§ page.person.print.photo.title: Photo
|
||||||
|
§ page.person.print.photo.description: space for a photo
|
||||||
|
§ page.person.total.title: Main characteristics
|
||||||
|
§ page.person.total.daysWorked.title: days of work
|
||||||
|
§ page.person.total.daysWorked.description: Only days with commits are counted
|
||||||
|
§ page.person.total.tasks.title: tasks
|
||||||
|
§ page.person.total.tasks.description: If commits are properly signed
|
||||||
|
§ page.person.character.title: Character
|
||||||
|
§ page.person.achievement.title: Achievements
|
||||||
|
§ page.person.achievement.positive: Positive
|
||||||
|
§ page.person.achievement.normal: Neutral
|
||||||
|
§ page.person.achievement.negative: Negative
|
||||||
|
§ page.person.achievement.description: The more negative achievements an employee accumulates, the higher the likelihood that the situation is unusual. It may be necessary to change their work mode, tasks, or reporting. A discussion with them to understand what problems are hindering their work is advisable.
|
||||||
|
§ page.person.gets.title: Gets taken:
|
||||||
|
§ page.person.gets.description: "Taking a get" in this context means being the first to leave a commit on a task with a "nice" number.
|
||||||
|
§ page.person.business.days.title: days of work
|
||||||
|
§ page.person.business.days.description: Only days with commits are counted
|
||||||
|
§ page.person.business.tasks.title: tasks
|
||||||
|
§ page.person.business.tasks.description: If commits are properly signed
|
||||||
|
§ page.person.business.losses.title: days without commits
|
||||||
|
§ page.person.business.losses.description: All days minus: holidays, weekends, vacation, days with commits
|
||||||
|
§ page.person.business.commits.title: commits
|
||||||
|
§ page.person.business.commits.description: Deleted branches are not counted
|
||||||
|
§ page.person.business.time.description: Time from the first to the last commit (including non-working days)
|
||||||
|
§ page.person.business.time.title: Days on the project:
|
||||||
|
§ page.person.business.time.dismissed: (dismissed)
|
||||||
|
§ page.person.business.time.staff: (not in the team)
|
||||||
|
§ page.person.business.achievements: Achievements
|
||||||
|
§ page.person.changes.title: Achievements
|
||||||
|
§ page.person.changes.description:
|
||||||
|
With some types of formatting, git marks lines as "deleted" and "added",
|
||||||
|
although in reality, they were "changed". Therefore, if you conducted a major refactoring,
|
||||||
|
git might show a small number of changes in the statistics, but the actual result
|
||||||
|
will be marked as a jump in "deleted" and "added" lines.
|
||||||
|
§ page.person.changes.description: List of commits and the number of changes in them for that day:
|
||||||
|
§ page.person.commits.title: List of commits:
|
||||||
|
§ page.person.money.title.total: Total over time
|
||||||
|
§ page.person.money.title.middle: Average cost
|
||||||
|
§ page.person.money.moneyAll.title: received
|
||||||
|
§ page.person.money.moneyAll.description: Assumed total salary from the project (see settings)
|
||||||
|
§ page.person.money.moneyWorked.title: worked for
|
||||||
|
§ page.person.money.moneyWorked.description: Actual days worked multiplied by average salary
|
||||||
|
§ page.person.money.moneyLosses.title: possible overpayment
|
||||||
|
§ page.person.money.moneyLosses.description: Days without commits multiplied by average salary
|
||||||
|
§ page.person.money.tasks.title: task
|
||||||
|
§ page.person.money.tasks.description: Number of closed tasks to the cost of the day
|
||||||
|
§ page.person.money.commits.title: commit
|
||||||
|
§ page.person.money.commits.description: Number of commits to the cost of the workday
|
||||||
|
§ page.person.speed.task: One task on average is
|
||||||
|
§ page.person.speed.max: Maximum speed per day
|
||||||
|
§ page.person.speed.days.title: days
|
||||||
|
§ page.person.speed.days.description: Refers to workdays, if commits are properly signed
|
||||||
|
§ page.person.speed.commits.title: commits
|
||||||
|
§ page.person.speed.commits.description: Top and bottom 10% of values are trimmed
|
||||||
|
§ page.person.speed.line.title: lines of code
|
||||||
|
§ page.person.speed.line.description: Top and bottom 10% of values are trimmed
|
||||||
|
§ page.person.speed.tasks.title: tasks
|
||||||
|
§ page.person.speed.tasks.description: A task may not be completed, but work should be done on it
|
||||||
|
§ page.person.speed.maxCommits.title: commits
|
||||||
|
§ page.person.speed.maxCommits.description: A task may not be completed, but work should be done on it
|
||||||
|
§ page.person.hours.title: Distribution of commits during each day of the week
|
||||||
|
§ page.person.week.date: Date
|
||||||
|
§ page.person.week.tasks: Number of tasks
|
||||||
|
§ page.person.week.workDays: Days with commits
|
||||||
|
§ page.person.week.taskInDay: Tasks per day
|
||||||
|
§ page.person.week.days: days
|
||||||
|
§ page.person.week.workDay: weekdays
|
||||||
|
§ page.person.week.weekends: weekends
|
||||||
|
`;
|
504
src/ts/translations/pt/recommendations.ts
Normal file
504
src/ts/translations/pt/recommendations.ts
Normal file
|
@ -0,0 +1,504 @@
|
||||||
|
export default `
|
||||||
|
§ recommendations.modal.cancel: Ok
|
||||||
|
§ recommendations.title
|
||||||
|
Recommendations and Facts
|
||||||
|
|
||||||
|
§ recommendations.timestamp.firstCommit.description
|
||||||
|
made the first commit
|
||||||
|
|
||||||
|
Day of the Week: $1
|
||||||
|
|
||||||
|
§ recommendations.timestamp.lastCommit.description
|
||||||
|
made the last commit
|
||||||
|
|
||||||
|
Day of the Week: $1
|
||||||
|
|
||||||
|
§ recommendations.timestamp.common.title: $1 days
|
||||||
|
§ recommendations.timestamp.allDays.description: from the first to the last commit (including weekends and holidays).
|
||||||
|
§ recommendations.timestamp.lossesDays.description: days without commits, even considering weekends, vacation, and public holidays.
|
||||||
|
§ recommendations.timestamp.weekendDays.description
|
||||||
|
working on weekends
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- employees burn out faster;
|
||||||
|
|
||||||
|
§ recommendations.timestamp.regularWeekendWord.title: Regular Overtime
|
||||||
|
§ recommendations.timestamp.sometimeWeekendWord.title: Occasional Overtime
|
||||||
|
§ recommendations.timestamp.weekendWord.description
|
||||||
|
It might be advisable to change the project manager, analyst, and architect.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- the quality of the product is usually low;
|
||||||
|
- some employees resign;
|
||||||
|
- new errors emerge due to the rush;
|
||||||
|
|
||||||
|
# Most likely:
|
||||||
|
- deadlines were incorrectly estimated at the beginning;
|
||||||
|
- technical specifications are missing;
|
||||||
|
- weak analytics;
|
||||||
|
- weak architecture (no architect was hired, and the team consists of mid-level developers);
|
||||||
|
- started writing code first, then planning;
|
||||||
|
- lack of proper processes to understand mistakes;
|
||||||
|
|
||||||
|
§ recommendations.timestamp.neverWeekendWord.title: Usually Without Overtime
|
||||||
|
§ recommendations.timestamp.neverWeekendWord.description
|
||||||
|
But sometimes it happens.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- employees burn out faster;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.not.title
|
||||||
|
No Parallel Work
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.not.description
|
||||||
|
any feature at any given time is done by one person.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is less than 1.3, we consider that there is usually no parallel work within most features;
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- increases bus factor;
|
||||||
|
- employees develop more slowly;
|
||||||
|
- difficult to properly check an employee's work;
|
||||||
|
|
||||||
|
# Why this is good:
|
||||||
|
- experts emerge who are deeply immersed in the subject area and can offer more quality solutions;
|
||||||
|
- most likely there are no merge conflicts;
|
||||||
|
- the project can quickly develop in different directions simultaneously;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.has.title
|
||||||
|
Some Work Done in Parallel
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.has.description
|
||||||
|
Sometimes a feature is worked on simultaneously by several people.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is from 1.3 to 2.0, we consider that some of the work within different features is sometimes done in parallel;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.every.title
|
||||||
|
Parallel Work
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.every.description
|
||||||
|
any feature at any given time is worked on by several people
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is more than two, we consider that most of the work within different features is usually done in parallel;
|
||||||
|
|
||||||
|
§ recommendations.scope.money
|
||||||
|
this is the estimated cost for the work on this project.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days spent on development are multiplied by the individual salaries of the developers;
|
||||||
|
|
||||||
|
To change the salary of each developer for a more accurate total, go to the "Settings" section.
|
||||||
|
|
||||||
|
# Is this too much or too little?
|
||||||
|
To answer this question, consider the following:
|
||||||
|
- Could a ready-made solution have been purchased for this amount of money?
|
||||||
|
- Could a better product have been developed for this amount of money?
|
||||||
|
|
||||||
|
If the answer to both questions is "yes," then perhaps developing from scratch was not worth the money spent.
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.everyHasOne.title
|
||||||
|
Bus factor = 1
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.everyHasOne.description
|
||||||
|
Most features are deeply understood by only one person.
|
||||||
|
It's necessary to rotate people.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- if employees resign, it will be difficult to continue their work;
|
||||||
|
- it’s impossible to control the quality of their code;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- more than 80% of commits in a feature are made by one person;
|
||||||
|
- the project has more than 60% of such features;
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.oneMaintainer
|
||||||
|
one person is deeply involved in a feature.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- if they resign, it will be hard to continue development;
|
||||||
|
- the quality of code-review decreases;
|
||||||
|
- it’s difficult to parallelize development when needed;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- more than 80% of commits in a feature are made by one person;
|
||||||
|
|
||||||
|
§ recommendations.scope.types.process.title
|
||||||
|
Poor Processes
|
||||||
|
|
||||||
|
§ recommendations.scope.types.process.description
|
||||||
|
Most features contain one type of task.
|
||||||
|
|
||||||
|
§ recommendations.scope.types.one
|
||||||
|
features contain one type of task.
|
||||||
|
|
||||||
|
§ recommendations.scope.types.common
|
||||||
|
It's possible that developers are incorrectly signing commits or the manager is entering the same type of tasks.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- it's impossible to hand over support to another team;
|
||||||
|
- it's impossible to release a "boxed" version;
|
||||||
|
- strong dependence on specific developers;
|
||||||
|
- a high number of errors and low code quality;
|
||||||
|
- potential slowdown in development in the future;
|
||||||
|
|
||||||
|
# The manager's mistake:
|
||||||
|
- viewing the product only from the perspective of a "working demo";
|
||||||
|
|
||||||
|
# What should be done:
|
||||||
|
- tests;
|
||||||
|
- bugs (identified through testing);
|
||||||
|
- refactoring (as architecture may change);
|
||||||
|
- documentation;
|
||||||
|
- style revisions (as a result of focus group feedback);
|
||||||
|
|
||||||
|
§ recommendations.scope.plan.title
|
||||||
|
Develop a Long-Term Plan
|
||||||
|
|
||||||
|
§ recommendations.scope.plan.description
|
||||||
|
taking architecture into account.
|
||||||
|
|
||||||
|
This plan should immediately focus on the most challenging tasks.
|
||||||
|
|
||||||
|
# Why the lack of a plan is bad:
|
||||||
|
- employees create a minimally viable version without planning for expansion points. After this, unscalable code is written, which slows down future features;
|
||||||
|
|
||||||
|
# The manager's mistake:
|
||||||
|
- they haven't shown how the product will develop further and where the growth points will be;
|
||||||
|
|
||||||
|
# How it should be done:
|
||||||
|
- a global product development plan is created;
|
||||||
|
- a global architecture development plan is created (with developers and DBAs);
|
||||||
|
- potential significant changes are discussed upfront at the schematic level;
|
||||||
|
|
||||||
|
§ recommendations.scope.cost.title
|
||||||
|
Evaluate Investment in a Feature
|
||||||
|
|
||||||
|
§ recommendations.scope.cost.description
|
||||||
|
in terms of potential profit.
|
||||||
|
|
||||||
|
Features that are expensive to develop but bring little profit may need to be postponed or even canceled. This will make the project more commercially successful.
|
||||||
|
|
||||||
|
§ recommendations.author.lotOfLazy
|
||||||
|
writes too little code.
|
||||||
|
|
||||||
|
# Should they be fired?
|
||||||
|
- are they a team leader, architect, or analyst?
|
||||||
|
- is this their primary project?
|
||||||
|
- are there any dependencies on them?
|
||||||
|
|
||||||
|
# Why it makes no sense to correct
|
||||||
|
The total costs for the developer are already more than the profit from their work.
|
||||||
|
If we believe that there were no objective hindrances to their work, then the person either does not want to work at all or is working on two projects simultaneously.
|
||||||
|
Firing and replacing them with a new employee seems justified from a statistical point of view.
|
||||||
|
|
||||||
|
§ recommendations.author.manyLazy
|
||||||
|
writes little code. Needs to be monitored.
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- in test samples, a good programmer writes code for more than 80% of the time;
|
||||||
|
- in this case, the indicator is between 60% and 80%;
|
||||||
|
|
||||||
|
# How to monitor:
|
||||||
|
- break tasks into 1..2 days;
|
||||||
|
- ask for a status update every day;
|
||||||
|
- ensure tasks are well defined and ready for development;
|
||||||
|
- arrange pair programming to check actual speed;
|
||||||
|
|
||||||
|
§ recommendations.author.oneTypeMans
|
||||||
|
receives too many monotonous tasks of the same type. Risk of burnout.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- if an employee burns out, their work speed will decrease;
|
||||||
|
- professional growth slows down;
|
||||||
|
- the likelihood of resignation increases;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- the type of task is determined for each commit;
|
||||||
|
- if more than 70% of tasks are of the same type, it means the person is doing the same thing repeatedly;
|
||||||
|
|
||||||
|
§ recommendations.author.workToday.title: Working $1
|
||||||
|
§ recommendations.author.workToday.description
|
||||||
|
on the project at this moment.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- more than 50% of workdays;
|
||||||
|
- have worked during the last 30 days;
|
||||||
|
|
||||||
|
§ recommendations.author.dismissed.title: Dismissed $1
|
||||||
|
§ recommendations.author.dismissed.description
|
||||||
|
or worked for a short period.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- worked at a normal pace (apparently, this is their main repository);
|
||||||
|
- no commits in the last month;
|
||||||
|
- vacation usually lasts 14 days (their absence does not resemble a vacation);
|
||||||
|
|
||||||
|
§ recommendations.author.staff.title: Assisting $1
|
||||||
|
§ recommendations.author.staff.description
|
||||||
|
People of other specializations who have committed something.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- this is not an open-source project;
|
||||||
|
- workdays less than 15% of the total number;
|
||||||
|
- modify roughly the same files;
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.openSource.title
|
||||||
|
Open Project
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.openSource.description
|
||||||
|
they do not work five days a week here.
|
||||||
|
|
||||||
|
The project may be closed, but this work pace is typical for open libraries on GitHub.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- statistics are taken for all active developers;
|
||||||
|
- the average number of working days and days without commits is calculated;
|
||||||
|
- for open-source libraries, working days are usually a maximum of 15..20%;
|
||||||
|
|
||||||
|
# Consequences
|
||||||
|
For projects where work is not constant, many indicators do not make sense. Therefore, indicators like days without commits, speed, etc., will be hidden.
|
||||||
|
|
||||||
|
Typically, such projects are assessed before starting the development of their own closed version. The most interesting indicators in this case are the probable cost and total development time.
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.easy.title
|
||||||
|
Light Workload
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.easy.description
|
||||||
|
too many days without commits. It is necessary to understand why the team is not writing code.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- take statistics from all active developers;
|
||||||
|
- calculate the average number of working days and days without commits;
|
||||||
|
- workload is considered light if the percentage of days without commits is between 5% and 20%;
|
||||||
|
|
||||||
|
# Possible reasons:
|
||||||
|
- there are actually no tasks;
|
||||||
|
- there are tasks, but they fit well with the current architecture;
|
||||||
|
- developers are distracted by meetings;
|
||||||
|
- the team is not working;
|
||||||
|
|
||||||
|
# Solutions:
|
||||||
|
- discuss the issue with the team;
|
||||||
|
- reduce task granularity so that one or two tasks can be completed in a day;
|
||||||
|
- introduce daily meetings to check the status of tasks;
|
||||||
|
- arrange pair programming sessions to ensure that the developer can work faster;
|
||||||
|
|
||||||
|
§ recommendations.author.manager.title
|
||||||
|
Set Deadlines
|
||||||
|
|
||||||
|
§ recommendations.author.manager.description
|
||||||
|
Every task should have a clear deadline.
|
||||||
|
|
||||||
|
This will prevent dragging out its completion for several days or weeks.
|
||||||
|
|
||||||
|
# Indicators to check:
|
||||||
|
- the number of days spent on one task by an employee;
|
||||||
|
- the number of days waiting for PR merge (PR statistics page);
|
||||||
|
|
||||||
|
§ recommendations.author.shorTalk.title
|
||||||
|
Conduct Daily Meetings
|
||||||
|
|
||||||
|
§ recommendations.author.shorTalk.description
|
||||||
|
they help stay informed about the project.
|
||||||
|
|
||||||
|
Do not stretch them by getting sidetracked on irrelevant topics.
|
||||||
|
|
||||||
|
# Questions the employee should answer:
|
||||||
|
- what was done;
|
||||||
|
- what will be done;
|
||||||
|
- are there any issues;
|
||||||
|
|
||||||
|
# Interruptions should occur if:
|
||||||
|
- they start describing minor details in-depth, which are not important;
|
||||||
|
- they steer the conversation away from the original plan;
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
Often an employee who does nothing tries to avoid the answer by telling a bunch of unnecessary details of their work. This lulls the participants' attention and stretches the time for a response. It creates an impression that they are busy, even though there was no actual work done.
|
||||||
|
|
||||||
|
§ recommendations.author.ipr.title
|
||||||
|
Develop a Training Plan
|
||||||
|
|
||||||
|
§ recommendations.author.ipr.description
|
||||||
|
for each employee.
|
||||||
|
|
||||||
|
*Individual training plan* is a list of goals and tasks that help a person develop in a certain area.
|
||||||
|
|
||||||
|
# How to create a plan:
|
||||||
|
- create a competency matrix;
|
||||||
|
- identify which competencies have the least knowledge and experience;
|
||||||
|
- find out which of these competencies are of interest to the employee;
|
||||||
|
- come up with 3..5 goals within each such competency for the next six months or a year;
|
||||||
|
- try to do something every month to achieve one goal;
|
||||||
|
- remind every month about the overall plan to achieve these goals;
|
||||||
|
|
||||||
|
# Does a manager need a plan?
|
||||||
|
Yes, the manager should also make a plan for themselves. If there is no higher-level manager, they should self-assess.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- employees become more loyal to the company;
|
||||||
|
- you get more qualified personnel for the same money;
|
||||||
|
|
||||||
|
§ recommendations.author.oneToOne.title
|
||||||
|
Conduct One-on-One Meetings Every Month
|
||||||
|
|
||||||
|
§ recommendations.author.oneToOne.description
|
||||||
|
it helps to identify problems at an early stage.
|
||||||
|
|
||||||
|
*One-to-one* is a regular personal meeting of a manager with a subordinate. Such meetings typically discuss everything important to the employee, what concerns them, and what they can share with the manager in private.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- easy to find out who is overburdened and who has free time;
|
||||||
|
- possible to prevent employee burnout;
|
||||||
|
- quick feedback can be obtained about processes that you might not notice;
|
||||||
|
- trust is built, making employees more loyal to the company;
|
||||||
|
- increases employee motivation and engagement;
|
||||||
|
|
||||||
|
§ recommendations.author.club.title
|
||||||
|
Go to a Bar
|
||||||
|
|
||||||
|
§ recommendations.author.club.description
|
||||||
|
once a month or two.
|
||||||
|
|
||||||
|
This will help build informal communication within the team and bring the team together, even if the interaction is brief.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- quick feedback can be obtained about processes that you might not notice;
|
||||||
|
- trust is built, making employees more loyal to the company;
|
||||||
|
- increases employee engagement;
|
||||||
|
|
||||||
|
§ recommendations.hour.onlyWork.title: No Weekends Here
|
||||||
|
§ recommendations.hour.onlyWork.description: The project manager should probably be fired.
|
||||||
|
§ recommendations.hour.weekends.title: Working on Weekends
|
||||||
|
§ recommendations.hour.weekends.description: The project manager should probably be checked.
|
||||||
|
§ recommendations.hour.easy.title: There Are Problems
|
||||||
|
§ recommendations.hour.easy.description: There are likely crunch times and work is needed on weekends.
|
||||||
|
§ recommendations.week.lazyDays.down.title: Fewer Absences
|
||||||
|
§ recommendations.week.lazyDays.down.description: this indicator has dropped over the last three weeks
|
||||||
|
§ recommendations.week.lazyDays.up.title: More Absences
|
||||||
|
§ recommendations.week.lazyDays.up.description: no tasks or stricter control is needed
|
||||||
|
§ recommendations.week.notWork.title: Consistently Underperforms
|
||||||
|
§ recommendations.week.notWork.description: as every week the code is not 100% of the time
|
||||||
|
§ recommendations.week.upWork.title: Consistently Overworks
|
||||||
|
§ recommendations.week.upWork.description: as every week code is written on weekend days
|
||||||
|
§ recommendations.week.task.up.title: Productivity is growing
|
||||||
|
§ recommendations.week.task.up.description: or tasks have become too small. Need to check. If granularity is the same - reinforce the result.
|
||||||
|
§ recommendations.week.task.lazyMaintainer.description: consistently leads in absences. Fire?
|
||||||
|
§ recommendations.week.task.down.title: Productivity is Falling
|
||||||
|
§ recommendations.week.task.down.description
|
||||||
|
or tasks are poorly split. Need to check. If granularity is the same - take control.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- the number of tasks per day that are being worked on has been steadily decreasing over the last three weeks.
|
||||||
|
|
||||||
|
# Possible errors:
|
||||||
|
- tasks could have been more complex than they seemed;
|
||||||
|
- tasks could have had a large volume of work (need to check if the number of changes is also decreasing during this period)
|
||||||
|
|
||||||
|
§ recommendations.type.everyHasOne.title: Not Signing Task Types
|
||||||
|
§ recommendations.type.everyHasOne.description: Most task types are done by one person.
|
||||||
|
§ recommendations.type.oneMaintainer.title: Narrow Specialization
|
||||||
|
§ recommendations.type.oneMaintainer.description
|
||||||
|
most tasks of one type are done by the same people.
|
||||||
|
|
||||||
|
# Task types:
|
||||||
|
|
||||||
|
§ recommendations.type.common
|
||||||
|
# It might not be the case
|
||||||
|
|
||||||
|
Make sure that other employees correctly sign commits.
|
||||||
|
|
||||||
|
Steps to ensure this:
|
||||||
|
- set up a pre-commit check for commit messages;
|
||||||
|
- explain to the team the need to indicate the type;
|
||||||
|
- check in new branches that employees follow this rule;
|
||||||
|
|
||||||
|
# If it is indeed the case
|
||||||
|
|
||||||
|
You have set up checks and ensured that the same employee does tasks of the same type.
|
||||||
|
|
||||||
|
Why this is bad:
|
||||||
|
- their resignation will halt a whole bunch of processes;
|
||||||
|
- it reduces the competence of other team members;
|
||||||
|
- difficult to understand their edits at a higher level;
|
||||||
|
|
||||||
|
How to fix this:
|
||||||
|
- distribute different types of tasks evenly;
|
||||||
|
- change the area of work (tests, documentation, bugs) among employees every sprint;
|
||||||
|
|
||||||
|
§ recommendations.type.fewTypes.title
|
||||||
|
This is a Local Product
|
||||||
|
|
||||||
|
§ recommendations.type.fewTypes.description
|
||||||
|
for a specific customer or problem.
|
||||||
|
|
||||||
|
# Signs of a "global" product:
|
||||||
|
- localization;
|
||||||
|
- documentation;
|
||||||
|
- a large volume of tests;
|
||||||
|
- visual customization;
|
||||||
|
- refactoring of bottlenecks;
|
||||||
|
- etc.
|
||||||
|
|
||||||
|
# Why this product looks like a "local" one:
|
||||||
|
- each "global" sign will be outweighed by its type of task;
|
||||||
|
- the more "global" signs, the more likely a "global" product;
|
||||||
|
|
||||||
|
In this case, we see a small number of types, which likely indicates shortcomings that prevent the product from being easily scaled to the global market and sold in other countries.
|
||||||
|
|
||||||
|
# It might not be the case
|
||||||
|
Based on file types, we can assume the type of program (website, server application, DevOps scripts, etc.). For a frontend application, our hypothesis will be more accurate than for DevOps scripts, which might just be a micro-module of initialization.
|
||||||
|
|
||||||
|
§ recommendations.type.diff.title
|
||||||
|
Break Down the Leading Type into Subtypes
|
||||||
|
|
||||||
|
§ recommendations.type.diff.description
|
||||||
|
to detail errors.
|
||||||
|
|
||||||
|
Typically, the task type labeled "bug fixing" is leading. This makes the statistics weakly detailed.
|
||||||
|
|
||||||
|
*If you encounter this situation*, you can break down this type into subtypes (e.g., based on the location of detection).
|
||||||
|
|
||||||
|
Consider several options for subtypes:
|
||||||
|
- fix_dev (error detected during development);
|
||||||
|
- fix_test (error detected during testing);
|
||||||
|
- fix (error detected in production);
|
||||||
|
|
||||||
|
§ recommendations.type.buddy.title
|
||||||
|
Accumulate Minor Tasks
|
||||||
|
|
||||||
|
§ recommendations.type.buddy.description
|
||||||
|
for new employees.
|
||||||
|
|
||||||
|
# If a task is:
|
||||||
|
- not important;
|
||||||
|
- not big;
|
||||||
|
- doesn't require deep immersion in the context;
|
||||||
|
- more about refactoring than new code;
|
||||||
|
|
||||||
|
# Put it in the backlog with the label "for beginners".
|
||||||
|
|
||||||
|
When a new employee arrives, you will be able to immediately pull out a bunch of small and varied tasks for them to get acquainted with the project.
|
||||||
|
|
||||||
|
Also, if you have a lull in work, you can pull out one such minor task from the backlog.
|
||||||
|
`;
|
27
src/ts/translations/pt/settings.ts
Normal file
27
src/ts/translations/pt/settings.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ page.settings.document.title: Display settings
|
||||||
|
§ page.settings.document.name: Page title
|
||||||
|
§ page.settings.document.language: Interface language
|
||||||
|
§ page.settings.links.title: Link prefixes
|
||||||
|
§ page.settings.links.task: For task numbers
|
||||||
|
§ page.settings.links.pr: For PR
|
||||||
|
§ page.settings.user.title: Individual settings
|
||||||
|
§ page.settings.user.notFound: No individual settings. Data for all employees are calculated based on common parameters.
|
||||||
|
§ page.settings.user.subTitle: Addendum to employment contract №$1
|
||||||
|
§ page.settings.user.from: Start date
|
||||||
|
§ page.settings.mailmap: .mailmap example
|
||||||
|
§ page.settings.common.title: General salary data
|
||||||
|
§ page.settings.common.type.title: Project work type
|
||||||
|
§ page.settings.common.type.full: Full-time employment
|
||||||
|
§ page.settings.common.type.part: Project work
|
||||||
|
§ page.settings.common.salary: Monthly salary
|
||||||
|
§ page.settings.common.currency: Currency
|
||||||
|
§ page.settings.common.workDaysInYear: Number of working days in a year
|
||||||
|
§ page.settings.common.vacationDaysInYear: Number of vacation days in a year
|
||||||
|
§ page.settings.common.workDaysInWeek: Workdays
|
||||||
|
§ page.settings.form.save: Save
|
||||||
|
§ page.settings.form.cancel: Cancel
|
||||||
|
§ page.settings.form.remove: Remove
|
||||||
|
§ page.settings.form.addEmployee: Add an employee
|
||||||
|
§ page.settings.form.addContract: Add an employment contract
|
||||||
|
`;
|
|
@ -1,27 +0,0 @@
|
||||||
export default `
|
|
||||||
§ uiKit.console.button: Копировать
|
|
||||||
§ uiKit.console.notification: Текст скопирован
|
|
||||||
§ uiKit.dataLoader.page: Страница
|
|
||||||
§ uiKit.dataLoader.size: Отображается по
|
|
||||||
§ uiKit.dataLoader.from: из
|
|
||||||
§ uiKit.dataLoader.all: Показать все
|
|
||||||
§ uiKit.hoursChart.work: стандартное рабочее время (будни, с 07:00 до 20:00)
|
|
||||||
§ uiKit.hoursChart.weekend: выходные дни или время до/после рабочего дня
|
|
||||||
§ uiKit.hoursChart.days: суммарное количество коммитов за все время в конкретный день и час
|
|
||||||
§ uiKit.page.remove: Удалить
|
|
||||||
§ uiKit.nothingFound.common.title: Нет или недостаточно данных для отображения
|
|
||||||
§ uiKit.nothingFound.common.description: Система обработает больше данных, если коммиты будут подписаны в формате [Git commit message convention|https://www.conventionalcommits.org/en/v1.0.0/]. Шаблон:
|
|
||||||
§ uiKit.nothingFound.common.console: Номер_задачи тип(фича): пояснение
|
|
||||||
§ uiKit.nothingFound.common.example: Например:
|
|
||||||
§ uiKit.nothingFound.staff.title: Нет данных для этого сотрудника
|
|
||||||
§ uiKit.nothingFound.staff.description1:
|
|
||||||
Он вносил правки не каждый рабочий день. Поэтому получил статус «Помошник».
|
|
||||||
Статистику сотрудника с таким статусом можно не учитывать. Его влад незначителен.
|
|
||||||
§ uiKit.nothingFound.staff.description2:
|
|
||||||
Система не рассчитывает для него ряд показателей.
|
|
||||||
Если это ошибка и статистику для данного сотрудника нужно учитывать, перейдите в раздел «Настройки» и измените его тип.
|
|
||||||
§ common.title: Git статистика
|
|
||||||
§ common.filters: Фильтры
|
|
||||||
§ common.notifications.save: Изменения сохранены
|
|
||||||
§ common.notifications.setting: Настройки сохранены
|
|
||||||
`;
|
|
|
@ -1,40 +0,0 @@
|
||||||
export default `
|
|
||||||
§ sidebar.switch.team: Команда
|
|
||||||
§ sidebar.switch.person: Сотрудник
|
|
||||||
§ sidebar.buttons.settings: Настройки
|
|
||||||
§ sidebar.buttons.print: Печать
|
|
||||||
§ sidebar.filters.all: всё время
|
|
||||||
§ sidebar.filters.year: год
|
|
||||||
§ sidebar.filters.halfYear: пол года
|
|
||||||
§ sidebar.filters.month: месяц
|
|
||||||
§ sidebar.filters.week: неделя
|
|
||||||
§ sidebar.team.total: Общая информация
|
|
||||||
§ sidebar.team.scope: Фичи
|
|
||||||
§ sidebar.team.author: Сотрудники
|
|
||||||
§ sidebar.team.type: Типы задач
|
|
||||||
§ sidebar.team.pr: Влитие кода
|
|
||||||
§ sidebar.team.day: По дням
|
|
||||||
§ sidebar.team.week: По неделям
|
|
||||||
§ sidebar.team.month: По месяцам
|
|
||||||
§ sidebar.team.tree: Анализ файлов
|
|
||||||
§ sidebar.team.files: Файлы
|
|
||||||
§ sidebar.team.removedFiles: Удалённые файлы
|
|
||||||
§ sidebar.team.tasks: Список задач
|
|
||||||
§ sidebar.team.hours: Расписание
|
|
||||||
§ sidebar.team.commits: Все коммиты
|
|
||||||
§ sidebar.team.changes: Все изменения
|
|
||||||
§ sidebar.team.words: Популярные слова
|
|
||||||
§ sidebar.team.top: Викторина
|
|
||||||
§ sidebar.team.settings: Настройки
|
|
||||||
§ sidebar.person.total: Общая информация
|
|
||||||
§ sidebar.person.money: Стоимость работы
|
|
||||||
§ sidebar.person.speed: Скорость
|
|
||||||
§ sidebar.person.day: По дням
|
|
||||||
§ sidebar.person.week: По неделям
|
|
||||||
§ sidebar.person.month: По месяцам
|
|
||||||
§ sidebar.person.hours: Расписание
|
|
||||||
§ sidebar.person.commits: Все коммиты
|
|
||||||
§ sidebar.person.changes: Все изменения
|
|
||||||
§ sidebar.person.words: Популярные слова
|
|
||||||
§ sidebar.person.settings: Настройки
|
|
||||||
`;
|
|
212
src/ts/translations/ru/pages_RU.txt
Normal file
212
src/ts/translations/ru/pages_RU.txt
Normal file
|
@ -0,0 +1,212 @@
|
||||||
|
export default `
|
||||||
|
§ page.welcome.step1: Выполните команду в корне вашего проекта
|
||||||
|
§ page.welcome.step3: Перетащите
|
||||||
|
§ page.welcome.step4: файл log.txt на эту страницу
|
||||||
|
§ page.welcome.description: Git создаст файл log.txt. Он содержит данные для построения отчёта. Выполните команду git shortlog -s -n -e если отчёт вам не нужен. Создайте файл [.mailmap|https://git-scm.com/docs/gitmailmap] в корне проекта, чтобы объединить статистику по сотрудникам.
|
||||||
|
§ page.welcome.warning1: Сервис НЕ ХРАНИТ и НЕ ПЕРЕДАЁТ ваши данные. Все расчёты выполняются на вашем компьютере.
|
||||||
|
§ page.welcome.warning2: Сервис НЕ СОБИРАЕТ СТАТИСТИКУ по проектам. Вы можете посмотреть [исходный код|https://github.com/bakhirev/assayo].
|
||||||
|
§ page.common.words.title: Статистика по словам
|
||||||
|
§ page.common.words.description: самое популярное слово. Встречается $1 раза.
|
||||||
|
§ page.common.commits.title: Количество коммитов по дням
|
||||||
|
§ page.common.commits.description: ($1) самый продуктивный день по числу коммитов.
|
||||||
|
§ page.common.commits.title2: $1 сделано коммитов: $2
|
||||||
|
§ page.common.filter.allUsers: Не имеет значения
|
||||||
|
§ page.print.modal.title: Что распечатываем?
|
||||||
|
§ page.print.modal.page: Текущую страницу
|
||||||
|
§ page.print.modal.type: Текущий раздел
|
||||||
|
§ page.print.modal.all: Всю статистику
|
||||||
|
§ page.print.modal.cancel: Отмена
|
||||||
|
§ page.print.tableOfContents: Оглавление
|
||||||
|
§ page.print.title: Отчёт по git-репозиторию
|
||||||
|
§ page.print.sub_title: «$1»
|
||||||
|
§ page.print.description: Данные для отчёта были получены из истории коммитов.
|
||||||
|
§ page.team.author.title: Статистика по сотрудникам
|
||||||
|
§ page.team.author.description1: Часть статистики (скорость работы, затраченные деньги и т.п.) по сотрудникам с типом «Помощник» не считается, т.к. это не постоянная роль в проекте. Их работа незначительно и её можно не учитывать.
|
||||||
|
§ page.team.author.description2: Сортировка по умолчанию — это сортировка по количеству задач и группам (текущие, уволенные, помогающие сотрудники).
|
||||||
|
§ page.team.author.types: Тип работ
|
||||||
|
§ page.team.author.commits: Commits
|
||||||
|
§ page.team.author.commitsSmall: commits
|
||||||
|
§ page.team.author.tasks: Задач
|
||||||
|
§ page.team.author.tasksSmall: задач
|
||||||
|
§ page.team.author.workedLosses: Дни с коммитами и без
|
||||||
|
§ page.team.author.worked: работа
|
||||||
|
§ page.team.author.losses: дни без commits
|
||||||
|
§ page.team.author.days: дней
|
||||||
|
§ page.team.author.daysForTask: Дней на задачу
|
||||||
|
§ page.team.author.scopes: Доработка
|
||||||
|
§ page.team.author.moneyAll: Денег получил
|
||||||
|
§ page.team.author.moneyWorked: Отработал
|
||||||
|
§ page.team.author.moneyLosses: Переплата
|
||||||
|
§ page.team.hours.title: Распределение работы в течении каждого дня недели
|
||||||
|
§ page.team.month.title: Календарь работы по проекту
|
||||||
|
§ page.team.scope.title: Статистика по фичам
|
||||||
|
§ page.team.scope.scope: Доработка
|
||||||
|
§ page.team.scope.days: Раб. дней
|
||||||
|
§ page.team.scope.authorsDays: Человеко-дней
|
||||||
|
§ page.team.scope.tasks: Задач
|
||||||
|
§ page.team.scope.commits: Commits
|
||||||
|
§ page.team.scope.commitsSmall: commits
|
||||||
|
§ page.team.scope.types: Тип работ
|
||||||
|
§ page.team.scope.authors: Персональный вклад
|
||||||
|
§ page.team.scope.cost: Стоимость
|
||||||
|
§ page.team.type.title: Статистика по типам задач
|
||||||
|
§ page.team.type.description: *Персональный вклад* считается по количеству коммитов, а не объему измененных строк или файлов. Поэтому следует так же смотреть раздел «Анализ файлов», чтобы оценить масштаб изменений.
|
||||||
|
§ page.team.type.type: Тип работы
|
||||||
|
§ page.team.type.tasks: Задач
|
||||||
|
§ page.team.type.tasksSmall: задач
|
||||||
|
§ page.team.type.days: Дней
|
||||||
|
§ page.team.type.daysSmall: дней
|
||||||
|
§ page.team.type.authorsDays: Человеко-дней
|
||||||
|
§ page.team.type.commits: Commits
|
||||||
|
§ page.team.type.authors: Персональный вклад
|
||||||
|
§ page.team.total.titleA: Объём работ
|
||||||
|
§ page.team.total.titleB: Стоимость
|
||||||
|
§ page.team.total.daysWorked.title: человеко-дней
|
||||||
|
§ page.team.total.daysWorked.description: Учтены только дни, в которые делались коммиты
|
||||||
|
§ page.team.total.commits.title: commits
|
||||||
|
§ page.team.total.commits.description: Удалённые ветки не считаются
|
||||||
|
§ page.team.total.daysLosses.title: дней без commits
|
||||||
|
§ page.team.total.daysLosses.description: Все дни минус: праздники, выходные, отпуск, дни с коммитами
|
||||||
|
§ page.team.total.employment.title: работает / уволилось
|
||||||
|
§ page.team.total.employment.description: Если сотрудник в течении месяца не сделал ни одного коммита, он считается уволенным
|
||||||
|
§ page.team.total.moneyAll.title: общая
|
||||||
|
§ page.team.total.moneyAll.description: Суммарные затраты на зарплату
|
||||||
|
§ page.team.total.moneyWorked.title: фактическая
|
||||||
|
§ page.team.total.moneyWorked.description: Фактически отработанные дни умноженные на среднюю зарплату
|
||||||
|
§ page.team.total.moneyLosses.title: возможная переплата
|
||||||
|
§ page.team.total.moneyLosses.description: Оплаченные рабочие дни, когда коммитов не было
|
||||||
|
§ page.team.total.weekendPayment.title: работа на выходных
|
||||||
|
§ page.team.total.weekendPayment.description: Суммарная переплата за работу в выходные дни
|
||||||
|
§ page.team.total.workSpeed.title: задач в день
|
||||||
|
§ page.team.total.workSpeed.description: Средняя скорость работы команды при текущем составе сотрудников
|
||||||
|
§ page.team.total.moneySpeed.title: в месяц
|
||||||
|
§ page.team.total.moneySpeed.description: Прогнозируемая сумма выплаты на зарплату при текущем составе сотрудников без учета налогов и сопутствующих затрат
|
||||||
|
§ page.team.total.description1: *Человеко-дни* — это работа одного сотрудника в течение одного рабочего дня. Например, за один календарный день, команда из трех сотрудников выдает объем работы в три человеко-дня.
|
||||||
|
§ page.team.total.description2: *Днями прогулов* считаются только рабочие дни, когда коммиты могли бы быть сделаны. Выходные, государственные праздники и отпуска в расчёте не участвуют.
|
||||||
|
§ page.team.total.description3: Карточка *работает и уволилось* показывает фактический состав сотрудников, которые постоянно участвуют в работе. Кроме этого, есть «помощники» — это сотрудники, как правило другой специализации, которые могут иногда делать коммиты в проект.
|
||||||
|
§ page.team.total.description4: *Переплатой* считаются только рабочие дни, когда коммиты могли бы быть сделаны. Выходные, государственные праздники и отпуска в расчёте не участвуют. Именно поэтому переплата + фактическая стоимость != общей. В общей стоимости заложена оплата выходных, государственных праздников и отпусков.
|
||||||
|
§ page.team.total.description5: *Работой на выходных* считается по коэффициенту х2 от оплаты обычного дня. Выше отображена именно переплата (х1), т.к. сам факт переработки в данном контексте не интересен. Мы не смотрим скорость сжигания бюджета. Мы смотрим переплату при увеличении скорости работы.
|
||||||
|
§ page.team.tree.title: Дерево проекта с учётом выбранных фильтров
|
||||||
|
§ page.team.tree.filters.author: Сотрудник
|
||||||
|
§ page.team.tree.filters.commits: Количество коммитов
|
||||||
|
§ page.team.tree.filters.help: Минимальное количество коммитов, которое сделал сотрудник в файле
|
||||||
|
§ page.team.tree.filters.all: Все сотрудники
|
||||||
|
§ page.team.tree.add: Кто добавлял
|
||||||
|
§ page.team.tree.change: Кто менял
|
||||||
|
§ page.team.tree.remove: Кто удалял
|
||||||
|
§ page.team.tree.line: строк
|
||||||
|
§ page.team.tree.lineAdd: добавили
|
||||||
|
§ page.team.tree.lineRemove: изменили
|
||||||
|
§ page.team.week.title: Статистика по неделям
|
||||||
|
§ page.team.week.date: Дата
|
||||||
|
§ page.team.week.numberTasks: Количество задач
|
||||||
|
§ page.team.week.people: Количество человек
|
||||||
|
§ page.team.week.line: Изменение строк
|
||||||
|
§ page.team.week.days: Дни с коммитами и без
|
||||||
|
§ page.team.week.lossesDetails: Кто не коммитил
|
||||||
|
§ page.team.week.add: добавили
|
||||||
|
§ page.team.week.change: изменили
|
||||||
|
§ page.team.week.remove: удалили
|
||||||
|
§ page.team.week.hasCommits: были коммиты
|
||||||
|
§ page.team.week.hasNotCommits: небыло коммитов
|
||||||
|
§ page.team.week.days: дней
|
||||||
|
§ page.team.week.tasks: задач
|
||||||
|
§ page.team.pr.task: Задача
|
||||||
|
§ page.team.pr.tasks: задач
|
||||||
|
§ page.team.pr.firstCommitTime: Первый коммит
|
||||||
|
§ page.team.pr.lastCommitTime: Последний
|
||||||
|
§ page.team.pr.workDays: Дней разработки
|
||||||
|
§ page.team.pr.delayDays: Дней ожидания влития
|
||||||
|
§ page.team.pr.commits: Коммиты
|
||||||
|
§ page.team.pr.date: Дата влития
|
||||||
|
§ page.team.pr.mergeAuthor: Влил
|
||||||
|
§ page.team.pr.author: Сотрудник
|
||||||
|
§ page.team.pr.middleTimeRelease: Среднее время поставки (дни)
|
||||||
|
§ page.team.pr.work: разработка
|
||||||
|
§ page.team.pr.delay: ожидание
|
||||||
|
§ page.team.pr.days: дней
|
||||||
|
§ page.team.pr.oneTaskDays: Время потраченное на одну задачу
|
||||||
|
§ page.team.pr.description1: *Время разработки* это разница времени от первого до последнего коммита по задаче. Не важно были перерывы в несколько дней между коммитами или нет. Сам факт какого-либо коммита увеличивает время.
|
||||||
|
§ page.team.pr.description2: *Время ожидания* это время между последним коммитом и влитием кода. Оно показывает фактический простой в ожидании чего-либо.
|
||||||
|
§ page.team.pr.description3: *Зачем отображать время разработки* без разбивки на кодинг и код-ревью? Затем, чтобы показать бизнесу фактическое время поставки кода. Ожидание тестирования, замечания на ревью, проблемы DevOps и прочие несовершенства процесса, как раз уже заложены в этот срок.
|
||||||
|
§ page.team.pr.statByAuthors: Статистика по сотрудникам
|
||||||
|
§ page.team.pr.longDelay: Длительное ожидание влития
|
||||||
|
§ page.team.tasks.task: Задача
|
||||||
|
§ page.team.tasks.author: Автор первого коммита
|
||||||
|
§ page.team.tasks.from: Первый коммит
|
||||||
|
§ page.team.tasks.to: Последний коммит
|
||||||
|
§ page.team.tasks.daysInWork: Дней в работе
|
||||||
|
§ page.team.tasks.commits: Количество коммитов
|
||||||
|
§ page.team.tasks.pr: Дата влития
|
||||||
|
§ page.team.tasks.prAuthor: Влил
|
||||||
|
§ page.team.tasks.prDelayDays: Дней ожидания влития
|
||||||
|
§ page.team.tasks.comments: Комментарии
|
||||||
|
§ page.person.print.photo.title: Фотография
|
||||||
|
§ page.person.print.photo.description: место для фотографии
|
||||||
|
§ page.person.total.title: Основные характеристики
|
||||||
|
§ page.person.total.daysWorked.title: дней работы
|
||||||
|
§ page.person.total.daysWorked.description: Учтены только дни, в которые делались коммиты
|
||||||
|
§ page.person.total.tasks.title: задач
|
||||||
|
§ page.person.total.tasks.description: Если коммиты правильно подписаны
|
||||||
|
§ page.person.character.title: Персонаж
|
||||||
|
§ page.person.achievement.title: Достижения
|
||||||
|
§ page.person.achievement.positive: Позитивные
|
||||||
|
§ page.person.achievement.normal: Нейтральные
|
||||||
|
§ page.person.achievement.negative: Негативные
|
||||||
|
§ page.person.achievement.description: Чем больше сотрудник набрал отрицательных достижений, тем больше вероятность, что ситуация нестандартная. Возможно, стоит изменить режим его работы, задачи или отчётность. Следует поговорить с ним и узнать, какие проблемы мешают его работе.
|
||||||
|
§ page.person.gets.title: Взятые геты:
|
||||||
|
§ page.person.gets.description: «Взять гет» в данном случае означает первым оставить коммит к задаче с «красивым» номером.
|
||||||
|
§ page.person.business.days.title: дней работы
|
||||||
|
§ page.person.business.days.description: Учтены только дни, в которые делались коммиты
|
||||||
|
§ page.person.business.tasks.title: задач
|
||||||
|
§ page.person.business.tasks.description: Если коммиты правильно подписаны
|
||||||
|
§ page.person.business.losses.title: дней без коммитов
|
||||||
|
§ page.person.business.losses.description: Все дни минус: праздники, выходные, отпуск, дни с коммитами
|
||||||
|
§ page.person.business.commits.title: коммитов
|
||||||
|
§ page.person.business.commits.description: Удалённые ветки не считаются
|
||||||
|
§ page.person.business.time.description: Время от первого, до последнего коммита (в том числе, нерабочие дни)
|
||||||
|
§ page.person.business.time.title: Дней на проекте:
|
||||||
|
§ page.person.business.time.dismissed: (уволен)
|
||||||
|
§ page.person.business.time.staff: (не в команде)
|
||||||
|
§ page.person.business.achievements: Достижения
|
||||||
|
§ page.person.changes.title: Достижения
|
||||||
|
§ page.person.changes.description:
|
||||||
|
При некоторых видах форматирования git отмечает строки как «удалённые» и «добавленные»,
|
||||||
|
хотя на самом деле они были «изменены». Поэтому, если вы провели большой рефакторинг,
|
||||||
|
git может показать малое количество изменений в статистике, а фактический результат
|
||||||
|
будет отмечен, как скачок «удаленных» и «добавленных» строк.
|
||||||
|
§ page.person.changes.description: Список коммитов и количество изменений в них за этот день:
|
||||||
|
§ page.person.commits.title: Список коммитов:
|
||||||
|
§ page.person.money.title.total: За всё время
|
||||||
|
§ page.person.money.title.middle: Средняя стоимость
|
||||||
|
§ page.person.money.moneyAll.title: получил
|
||||||
|
§ page.person.money.moneyAll.description: Предполагаемая сумма зп с проекта (см. настройки)
|
||||||
|
§ page.person.money.moneyWorked.title: отработал
|
||||||
|
§ page.person.money.moneyWorked.description: Фактически отработанные дни умноженные на среднюю зп
|
||||||
|
§ page.person.money.moneyLosses.title: возможная переплата
|
||||||
|
§ page.person.money.moneyLosses.description: Дни без коммитов умноженные на среднюю зп
|
||||||
|
§ page.person.money.tasks.title: задача
|
||||||
|
§ page.person.money.tasks.description: Количество закрытых задач к стоимости дня
|
||||||
|
§ page.person.money.commits.title: коммит
|
||||||
|
§ page.person.money.commits.description: Количество коммитов к стоимости рабочего дня
|
||||||
|
§ page.person.speed.task: Одна задача в среднем это
|
||||||
|
§ page.person.speed.max: Максимальная скорость в день
|
||||||
|
§ page.person.speed.days.title: дней
|
||||||
|
§ page.person.speed.days.description: Имеются ввиду рабочие дни, если коммиты правильно подписаны
|
||||||
|
§ page.person.speed.commits.title: коммитов
|
||||||
|
§ page.person.speed.commits.description: Отрезаны 10% максимальных и минимальных значений
|
||||||
|
§ page.person.speed.line.title: строк кода
|
||||||
|
§ page.person.speed.line.description: Отрезаны 10% максимальных и минимальных значений
|
||||||
|
§ page.person.speed.tasks.title: задач
|
||||||
|
§ page.person.speed.tasks.description: Задача может быть не доделана, но работа по ней должна быть
|
||||||
|
§ page.person.speed.maxCommits.title: коммитов
|
||||||
|
§ page.person.speed.maxCommits.description: Задача может быть не доделана, но работа по ней должна быть
|
||||||
|
§ page.person.hours.title: Распределение коммитов в течении каждого дня недели
|
||||||
|
§ page.person.week.date: Дата
|
||||||
|
§ page.person.week.tasks: Количество задач
|
||||||
|
§ page.person.week.workDays: Дни с коммитами
|
||||||
|
§ page.person.week.taskInDay: Задач в день
|
||||||
|
§ page.person.week.days: дней
|
||||||
|
§ page.person.week.workDay: будни
|
||||||
|
§ page.person.week.weekends: выходные
|
||||||
|
`;
|
|
@ -36,7 +36,7 @@ export default `
|
||||||
|
|
||||||
# Скорее всего:
|
# Скорее всего:
|
||||||
- неверно оценили сроки в самом начале;
|
- неверно оценили сроки в самом начале;
|
||||||
- тех. задание отсутствует;
|
- техническое задание отсутствует;
|
||||||
- слабая аналитика;
|
- слабая аналитика;
|
||||||
- слабая архитектура (архитектора не нанимали, а команда состоит из мидл разработчиков);
|
- слабая архитектура (архитектора не нанимали, а команда состоит из мидл разработчиков);
|
||||||
- сначала начали писать код, потом проектировать;
|
- сначала начали писать код, потом проектировать;
|
||||||
|
@ -105,8 +105,8 @@ export default `
|
||||||
|
|
||||||
# Это много или мало?
|
# Это много или мало?
|
||||||
Для ответа на этот вопрос, нужно ответить на следующие:
|
Для ответа на этот вопрос, нужно ответить на следующие:
|
||||||
- Можно ли за эти деньги было купить готовое решение?
|
- за эти деньги можно купить готовое решение?
|
||||||
- Можно ли за эти деньги сделать более хороший продукт?
|
- за эти деньги можно сделать более хороший продукт?
|
||||||
|
|
||||||
Если ответ на оба вопроса «да», то возможно, разработка с нуля не стоила потраченных на неё денег.
|
Если ответ на оба вопроса «да», то возможно, разработка с нуля не стоила потраченных на неё денег.
|
||||||
|
|
||||||
|
|
92
src/ts/translations/zh/achievements.ts
Normal file
92
src/ts/translations/zh/achievements.ts
Normal file
|
@ -0,0 +1,92 @@
|
||||||
|
export default `
|
||||||
|
§ achievements.commitsAfter1500.title: Owl
|
||||||
|
§ achievements.commitsAfter1500.description: 70% of commits after 3:00 PM
|
||||||
|
§ achievements.commitsBefore1500.title: Early bird
|
||||||
|
§ achievements.commitsBefore1500.description: 70% of commits before noon
|
||||||
|
§ achievements.workEveryTime.title: Devoted worker
|
||||||
|
§ achievements.workEveryTime.description: a commit for every hour of the day
|
||||||
|
§ achievements.workNotWork.title: Shooting blanks
|
||||||
|
§ achievements.workNotWork.description: commits are there, but no tasks are closed
|
||||||
|
§ achievements.userNotWork.title: Fly-by
|
||||||
|
§ achievements.userNotWork.description: this is not their main project
|
||||||
|
§ achievements.userIsDied.title: Dead soul
|
||||||
|
§ achievements.userIsDied.description: worked, but resigned
|
||||||
|
§ achievements.lessTasks.title: Came and went
|
||||||
|
§ achievements.lessTasks.description: least closed tasks
|
||||||
|
§ achievements.moreTasks.title: Father says well done
|
||||||
|
§ achievements.moreTasks.description: most closed tasks
|
||||||
|
§ achievements.everyMessageLong.title: Master of eloquence
|
||||||
|
§ achievements.everyMessageLong.description: consistently the longest commit messages
|
||||||
|
§ achievements.everyMessageShort.title: Talkative, a spy's dream
|
||||||
|
§ achievements.everyMessageShort.description: consistently, the shortest commit messages
|
||||||
|
§ achievements.shortestName.title: Size doesn't matter
|
||||||
|
§ achievements.shortestName.description: shortest name
|
||||||
|
§ achievements.longestName.title: Azim Aziz Il Am Kadir Imran II
|
||||||
|
§ achievements.longestName.description: longest name
|
||||||
|
§ achievements.moreCommits.title: Backup master
|
||||||
|
§ achievements.moreCommits.description: most commits
|
||||||
|
§ achievements.lessCommits.title: Rare but Precise
|
||||||
|
§ achievements.lessCommits.description: least commits
|
||||||
|
§ achievements.oneCommitOneTask.title: Right on target
|
||||||
|
§ achievements.oneCommitOneTask.description: on average one commit per task
|
||||||
|
§ achievements.moreLazyDays.title: With you in spirit
|
||||||
|
§ achievements.moreLazyDays.description: most days without commits
|
||||||
|
§ achievements.lessLazyDays.title: Papa carlo
|
||||||
|
§ achievements.lessLazyDays.description: least days without commits
|
||||||
|
§ achievements.zeroLazyDays.title: Not a single break
|
||||||
|
§ achievements.zeroLazyDays.description: not a single day without commits
|
||||||
|
§ achievements.moreWorkDays.title: Valuable employee
|
||||||
|
§ achievements.moreWorkDays.description: most working days
|
||||||
|
§ achievements.moreScopes.title: Startuper
|
||||||
|
§ achievements.moreScopes.description: completed the most features
|
||||||
|
§ achievements.lessScopes.title: Dandy
|
||||||
|
§ achievements.lessScopes.description: completed the fewest features
|
||||||
|
§ achievements.moreDaysForTask.title: Snail on the slope
|
||||||
|
§ achievements.moreDaysForTask.description: tasks take longer than others
|
||||||
|
§ achievements.more2DaysForTask.title: Slow and steady
|
||||||
|
§ achievements.more2DaysForTask.description: more than two days per task
|
||||||
|
§ achievements.moreDaysInProject.title: Old-timer
|
||||||
|
§ achievements.moreDaysInProject.description: most days in the project
|
||||||
|
§ achievements.lessDaysInProject.title: And who is this?
|
||||||
|
§ achievements.lessDaysInProject.description: least days in the project
|
||||||
|
§ achievements.more90DaysInProject.title: Welcome aboard
|
||||||
|
§ achievements.more90DaysInProject.description: not fired during the probation period
|
||||||
|
§ achievements.lessDaysForTask.title: Quick draw
|
||||||
|
§ achievements.lessDaysForTask.description: a task takes less than a day
|
||||||
|
§ achievements.adam.title: Adam
|
||||||
|
§ achievements.adam.description: the first stable employee on the project
|
||||||
|
§ achievements.more666DaysInProject.title: Devil
|
||||||
|
§ achievements.more666DaysInProject.description: worked 666 days on the project
|
||||||
|
§ achievements.more777DaysInProject.title: Azino three axes
|
||||||
|
§ achievements.more777DaysInProject.description: worked 777 days on the project
|
||||||
|
§ achievements.moreRefactoring.title: Executive editor
|
||||||
|
§ achievements.moreRefactoring.description: made the most 'refactoring' tags
|
||||||
|
§ achievements.longestMessage.title: So many conversations...
|
||||||
|
§ achievements.longestMessage.description: the longest commit message of all time
|
||||||
|
§ achievements.moreTasksInDay.title: Speed racer
|
||||||
|
§ achievements.moreTasksInDay.description: record for the number of tasks closed in a day
|
||||||
|
§ achievements.hasCommitFrom0to7.title: Night watch
|
||||||
|
§ achievements.hasCommitFrom0to7.description: a commit for every hour of the night
|
||||||
|
§ achievements.noCommitOnDay.title: Technical break
|
||||||
|
§ achievements.noCommitOnDay.description: there is a certain hour and day in working time when never commits
|
||||||
|
§ achievements.hasCommitEveryTime.title: Died at work
|
||||||
|
§ achievements.hasCommitEveryTime.description: a commit for every hour of each day (including weekends)
|
||||||
|
§ achievements.commitsAfter1800.title: Business Time
|
||||||
|
§ achievements.commitsAfter1800.description: no commits after 6:00 PM
|
||||||
|
§ achievements.more1488DaysInProject.title: Named after Maxim Martsinkevich
|
||||||
|
§ achievements.more1488DaysInProject.description: worked 1488 days on the project
|
||||||
|
§ achievements.moreFix.title: Bug hunter
|
||||||
|
§ achievements.moreFix.description: most closed bugs
|
||||||
|
§ achievements.lessWorkDays.title: Count me out
|
||||||
|
§ achievements.lessWorkDays.description: least working days
|
||||||
|
§ achievements.moreCreateCode.title: Creator
|
||||||
|
§ achievements.moreCreateCode.description: tends to add code more than others
|
||||||
|
§ achievements.moreRemoveCode.title: Destroyer
|
||||||
|
§ achievements.moreRemoveCode.description: tends to remove code more than others
|
||||||
|
§ achievements.moreChangeCode.title: Reformer
|
||||||
|
§ achievements.moreChangeCode.description: tends to change code more than others
|
||||||
|
§ achievements.moreStyle.title: Fashion police
|
||||||
|
§ achievements.moreStyle.description: tends to change CSS more than others
|
||||||
|
§ achievements.moreOnHoliday.title: No life
|
||||||
|
§ achievements.moreOnHoliday.description: relatively many commits in non-working hours
|
||||||
|
`;
|
27
src/ts/translations/zh/common.ts
Normal file
27
src/ts/translations/zh/common.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ uiKit.console.button: 副本
|
||||||
|
§ uiKit.console.notification: 文本已被复制
|
||||||
|
§ uiKit.dataLoader.page: 页面
|
||||||
|
§ uiKit.dataLoader.size: 显示的
|
||||||
|
§ uiKit.dataLoader.from: 从
|
||||||
|
§ uiKit.dataLoader.all: 全部展示
|
||||||
|
§ uiKit.hoursChart.work: 标准工作时间 (平日07:00~20:00)
|
||||||
|
§ uiKit.hoursChart.weekend: 工作日之前/之后的休息日或时间
|
||||||
|
§ uiKit.hoursChart.days: 特定日期和小时内所有时间的提交总数
|
||||||
|
§ uiKit.page.remove: 移走
|
||||||
|
§ uiKit.nothingFound.common.title: 没有或不足的数据显示
|
||||||
|
§ uiKit.nothingFound.common.description: 如果提交以该格式签名,系统将处理更多数据 [Git commit message convention|https://www.conventionalcommits.org/en/v1.0.0/]. 模型:
|
||||||
|
§ uiKit.nothingFound.common.console: 发行编号类别(功能): 解释说明
|
||||||
|
§ uiKit.nothingFound.common.example: 例如:
|
||||||
|
§ uiKit.nothingFound.staff.title: 没有这个员工的数据
|
||||||
|
§ uiKit.nothingFound.staff.description1:
|
||||||
|
他不每天工作,所以获得了“助理”职务。
|
||||||
|
可以不考虑带有这种职称的员工的统计数据。他的贡献很小。
|
||||||
|
§ uiKit.nothingFound.staff.description2:
|
||||||
|
系统不会为其计算若干指标。
|
||||||
|
如果这是一个错误,并且需要考虑这个员工的数据,请转到“设置”部分并更改他的类型。
|
||||||
|
§ common.title: Git 统计数字
|
||||||
|
§ common.filters: 过滤器
|
||||||
|
§ common.notifications.save: 将保存更改
|
||||||
|
§ common.notifications.setting: 设置被保存
|
||||||
|
`;
|
15
src/ts/translations/zh/index.ts
Normal file
15
src/ts/translations/zh/index.ts
Normal file
|
@ -0,0 +1,15 @@
|
||||||
|
import achievements from './achievements';
|
||||||
|
import common from './common';
|
||||||
|
import navigation from './navigation';
|
||||||
|
import recommendations from './recommendations';
|
||||||
|
import settings from './settings';
|
||||||
|
import pages from './pages';
|
||||||
|
|
||||||
|
export default [
|
||||||
|
achievements,
|
||||||
|
common,
|
||||||
|
navigation,
|
||||||
|
recommendations,
|
||||||
|
settings,
|
||||||
|
pages,
|
||||||
|
].join('');
|
40
src/ts/translations/zh/navigation.ts
Normal file
40
src/ts/translations/zh/navigation.ts
Normal file
|
@ -0,0 +1,40 @@
|
||||||
|
export default `
|
||||||
|
§ sidebar.switch.team: 专责小组
|
||||||
|
§ sidebar.switch.person: 雇员
|
||||||
|
§ sidebar.buttons.settings: 设置
|
||||||
|
§ sidebar.buttons.print: 印刷业
|
||||||
|
§ sidebar.filters.all: 一直
|
||||||
|
§ sidebar.filters.year: 年份
|
||||||
|
§ sidebar.filters.halfYear: 半年
|
||||||
|
§ sidebar.filters.month: 月份
|
||||||
|
§ sidebar.filters.week: 一周
|
||||||
|
§ sidebar.team.total: 一般资料
|
||||||
|
§ sidebar.team.scope: 功能
|
||||||
|
§ sidebar.team.author: 员工
|
||||||
|
§ sidebar.team.type: 任务类型
|
||||||
|
§ sidebar.team.pr: 代码注入
|
||||||
|
§ sidebar.team.day: 白天
|
||||||
|
§ sidebar.team.week: 按星期计算
|
||||||
|
§ sidebar.team.month: 按月计算
|
||||||
|
§ sidebar.team.tree: 文件分析
|
||||||
|
§ sidebar.team.files: 档案
|
||||||
|
§ sidebar.team.removedFiles: 删除的文件
|
||||||
|
§ sidebar.team.tasks: 任务列表
|
||||||
|
§ sidebar.team.hours: 时间表
|
||||||
|
§ sidebar.team.commits: All commits
|
||||||
|
§ sidebar.team.changes: 所有更改
|
||||||
|
§ sidebar.team.words: 流行语
|
||||||
|
§ sidebar.team.top: 测验
|
||||||
|
§ sidebar.team.settings: 设置
|
||||||
|
§ sidebar.person.total: 一般资料
|
||||||
|
§ sidebar.person.money: 工作的成本
|
||||||
|
§ sidebar.person.speed: 速度
|
||||||
|
§ sidebar.person.day: 白天
|
||||||
|
§ sidebar.person.week: 按星期计算
|
||||||
|
§ sidebar.person.month: 按月计算
|
||||||
|
§ sidebar.person.hours: 时间表
|
||||||
|
§ sidebar.person.commits: All commits
|
||||||
|
§ sidebar.person.changes: 所有更改
|
||||||
|
§ sidebar.person.words: 流行语
|
||||||
|
§ sidebar.person.settings: 设置
|
||||||
|
`;
|
212
src/ts/translations/zh/pages.ts
Normal file
212
src/ts/translations/zh/pages.ts
Normal file
|
@ -0,0 +1,212 @@
|
||||||
|
export default `
|
||||||
|
§ page.welcome.step1: Execute the command in the root of your project.
|
||||||
|
§ page.welcome.step3: Drag and drop
|
||||||
|
§ page.welcome.step4: the log.txt file onto this page.
|
||||||
|
§ page.welcome.description: Git will create a log.txt file. It contains data for report generation. Or use git shortlog -s -n -e if you don't need a report. Create a [.mailmap|https://git-scm.com/docs/gitmailmap] file in the root of the project to consolidate employee statistics.
|
||||||
|
§ page.welcome.warning1: The service *DOES NOT SAVE* and *DOES NOT TRANSFER* your data. All calculations are performed locally in your browser on your machine.
|
||||||
|
§ page.welcome.warning2: The service *DOES NOT COLLECT STATISTICS* on projects. You can disconnect the internet, check traffic, and even build a local version from the [source|https://github.com/bakhirev/assayo].
|
||||||
|
§ page.common.words.title: Word Statistics.
|
||||||
|
§ page.common.words.description: the most popular word. Occurs $1 times.
|
||||||
|
§ page.common.commits.title: Number of commits by days.
|
||||||
|
§ page.common.commits.description: ($1) the most productive day in terms of the number of commits.
|
||||||
|
§ page.common.commits.title2: $1 commits made: $2
|
||||||
|
§ page.common.filter.allUsers: Does not matter
|
||||||
|
§ page.print.modal.title: What are we printing?
|
||||||
|
§ page.print.modal.page: Current page
|
||||||
|
§ page.print.modal.type: Current section
|
||||||
|
§ page.print.modal.all: All statistics
|
||||||
|
§ page.print.modal.cancel: Cancel
|
||||||
|
§ page.print.tableOfContents: Table of contents
|
||||||
|
§ page.print.title: Git repository report
|
||||||
|
§ page.print.sub_title: «$1»
|
||||||
|
§ page.print.description: The data for the report was obtained from the commit history.
|
||||||
|
§ page.team.author.title: Employee statistics
|
||||||
|
§ page.team.author.description1: *Part of the statistics* (work speed, costs, etc.) *for employees with the 'Assistant' type is not counted*, as it is an episodic role in the project. It is assumed that they do not affect the project, and their edits can be disregarded in the context of the overall volume of work.
|
||||||
|
§ page.team.author.description2: *Default sorting* is by the number of tasks and groups (current, fired, assisting employees).
|
||||||
|
§ page.team.author.types: Types of work
|
||||||
|
§ page.team.author.commits: Commits
|
||||||
|
§ page.team.author.commitsSmall: commits
|
||||||
|
§ page.team.author.tasks: Tasks
|
||||||
|
§ page.team.author.tasksSmall: tasks
|
||||||
|
§ page.team.author.workedLosses: Days with and without commits
|
||||||
|
§ page.team.author.worked: work
|
||||||
|
§ page.team.author.losses: days without commits
|
||||||
|
§ page.team.author.days: days
|
||||||
|
§ page.team.author.daysForTask: Days per task
|
||||||
|
§ page.team.author.scopes: Features
|
||||||
|
§ page.team.author.moneyAll: Received
|
||||||
|
§ page.team.author.moneyWorked: Worked for
|
||||||
|
§ page.team.author.moneyLosses: Overpayment
|
||||||
|
§ page.team.hours.title: Distribution of commits during each day of the week
|
||||||
|
§ page.team.month.title: Project work calendar
|
||||||
|
§ page.team.scope.title: Feature statistics
|
||||||
|
§ page.team.scope.scope: Feature
|
||||||
|
§ page.team.scope.days: Working Days
|
||||||
|
§ page.team.scope.authorsDays: Person-Days
|
||||||
|
§ page.team.scope.tasks: Tasks
|
||||||
|
§ page.team.scope.commits: Commits
|
||||||
|
§ page.team.scope.commitsSmall: commits
|
||||||
|
§ page.team.scope.types: Types of work
|
||||||
|
§ page.team.scope.authors: Personal contribution
|
||||||
|
§ page.team.scope.cost: Cost
|
||||||
|
§ page.team.type.title: Task type statistics
|
||||||
|
§ page.team.type.description: *Personal contribution* is counted by the number of commits, not the volume of changed lines or files. Therefore, the "File Analysis" section should also be consulted to assess the scale of changes.
|
||||||
|
§ page.team.type.type: Type of work
|
||||||
|
§ page.team.type.tasks: Tasks
|
||||||
|
§ page.team.type.tasksSmall: tasks
|
||||||
|
§ page.team.type.days: Days
|
||||||
|
§ page.team.type.daysSmall: days
|
||||||
|
§ page.team.type.authorsDays: Person-days
|
||||||
|
§ page.team.type.commits: Commits
|
||||||
|
§ page.team.type.authors: Personal contribution
|
||||||
|
§ page.team.total.titleA: Volume of work
|
||||||
|
§ page.team.total.titleB: Cost
|
||||||
|
§ page.team.total.daysWorked.title: person-days
|
||||||
|
§ page.team.total.daysWorked.description: Only days with commits are counted
|
||||||
|
§ page.team.total.commits.title: commits
|
||||||
|
§ page.team.total.commits.description: Deleted branches are not counted
|
||||||
|
§ page.team.total.daysLosses.title: days without commits
|
||||||
|
§ page.team.total.daysLosses.description: All days minus: holidays, weekends, vacation, days with commits
|
||||||
|
§ page.team.total.employment.title: working / dismissed
|
||||||
|
§ page.team.total.employment.description: If an employee does not make any commits within a month, they are considered dismissed
|
||||||
|
§ page.team.total.moneyAll.title: total
|
||||||
|
§ page.team.total.moneyAll.description: Total salary expenses
|
||||||
|
§ page.team.total.moneyWorked.title: actual
|
||||||
|
§ page.team.total.moneyWorked.description: Actual days worked multiplied by average salary
|
||||||
|
§ page.team.total.moneyLosses.title: possible overpayment
|
||||||
|
§ page.team.total.moneyLosses.description: Paid working days when there were no commits
|
||||||
|
§ page.team.total.weekendPayment.title: weekend work
|
||||||
|
§ page.team.total.weekendPayment.description: Total overpayment for weekend work
|
||||||
|
§ page.team.total.workSpeed.title: tasks per day
|
||||||
|
§ page.team.total.workSpeed.description: Average work speed of the team with the current composition of employees
|
||||||
|
§ page.team.total.moneySpeed.title: per month
|
||||||
|
§ page.team.total.moneySpeed.description: Forecasted salary payment amount with the current team composition, excluding taxes and related expenses
|
||||||
|
§ page.team.total.description1: *Person-days* — the work of one employee during a single working day. For example, in one calendar day, a team of three employees produces a work volume of three person-days.
|
||||||
|
§ page.team.total.description2: *Absentee days* are counted only as working days when commits could have been made. Weekends, public holidays, and vacations are not included in the calculation.
|
||||||
|
§ page.team.total.description3: The *working and dismissed* card shows the actual composition of employees who are continuously involved in work. Additionally, there are "assistants" — typically employees of a different specialization who may occasionally make commits to the project.
|
||||||
|
§ page.team.total.description4: *Overpayment* includes only working days when commits could have been made. Weekends, public holidays, and vacations are not included in the calculation. This is why overpayment + actual cost != total. The total cost includes payment for weekends, public holidays, and vacations.
|
||||||
|
§ page.team.total.description5: *Weekend work* is calculated at a rate of x2 the payment of a regular day. The displayed amount is specifically the overpayment (x1), as the fact of overtime in this context is not of interest. We focus on overpayment when increasing work speed.
|
||||||
|
§ page.team.tree.title: Project Tree Considering Selected Filters
|
||||||
|
§ page.team.tree.filters.author: Employee
|
||||||
|
§ page.team.tree.filters.commits: Number of commits
|
||||||
|
§ page.team.tree.filters.help: The minimum number of commits an employee has made in a file
|
||||||
|
§ page.team.tree.filters.all: All employees
|
||||||
|
§ page.team.tree.add: Who added
|
||||||
|
§ page.team.tree.change: Who changed
|
||||||
|
§ page.team.tree.remove: Who removed
|
||||||
|
§ page.team.tree.line: lines
|
||||||
|
§ page.team.tree.lineAdd: added
|
||||||
|
§ page.team.tree.lineRemove: changed
|
||||||
|
§ page.team.week.title: Weekly statistics
|
||||||
|
§ page.team.week.date: Date
|
||||||
|
§ page.team.week.numberTasks: Number of tasks
|
||||||
|
§ page.team.week.people: Number of people
|
||||||
|
§ page.team.week.line: Line Changes
|
||||||
|
§ page.team.week.days: Days with and without commits
|
||||||
|
§ page.team.week.lossesDetails: Who did not commit
|
||||||
|
§ page.team.week.add: added
|
||||||
|
§ page.team.week.change: changed
|
||||||
|
§ page.team.week.remove: removed
|
||||||
|
§ page.team.week.hasCommits: had commits
|
||||||
|
§ page.team.week.hasNotCommits: had no commits
|
||||||
|
§ page.team.week.days: days
|
||||||
|
§ page.team.week.tasks: tasks
|
||||||
|
§ page.team.pr.task: Task
|
||||||
|
§ page.team.pr.tasks: tasks
|
||||||
|
§ page.team.pr.firstCommitTime: First commit
|
||||||
|
§ page.team.pr.lastCommitTime: Last
|
||||||
|
§ page.team.pr.workDays: Development days
|
||||||
|
§ page.team.pr.delayDays: Days waiting for merge
|
||||||
|
§ page.team.pr.commits: Commits
|
||||||
|
§ page.team.pr.date: Merge Date
|
||||||
|
§ page.team.pr.mergeAuthor: Merged by
|
||||||
|
§ page.team.pr.author: Employee
|
||||||
|
§ page.team.pr.middleTimeRelease: Average delivery time (days)
|
||||||
|
§ page.team.pr.work: development
|
||||||
|
§ page.team.pr.delay: waiting
|
||||||
|
§ page.team.pr.days: days
|
||||||
|
§ page.team.pr.oneTaskDays: Time spent on one task
|
||||||
|
§ page.team.pr.description1: *Development time* is the time difference from the first to the last commit on a task. It does not matter if there were breaks of several days between commits or not. Any commit increases the time.
|
||||||
|
§ page.team.pr.description2: *Waiting time* is the time between the last commit and the code merge. It shows the actual downtime while waiting for something.
|
||||||
|
§ page.team.pr.description3: *Why display development time* without splitting into coding and code review? To show the business the actual delivery time of the code. Waiting for testing, review comments, DevOps problems, and other process imperfections are already included in this term.
|
||||||
|
§ page.team.pr.statByAuthors: Statistics by employees
|
||||||
|
§ page.team.pr.longDelay: Prolonged Waiting for merge
|
||||||
|
§ page.team.tasks.task: Task
|
||||||
|
§ page.team.tasks.author: First commit author
|
||||||
|
§ page.team.tasks.from: First commit
|
||||||
|
§ page.team.tasks.to: Last commit
|
||||||
|
§ page.team.tasks.daysInWork: Days in work
|
||||||
|
§ page.team.tasks.commits: Commits number
|
||||||
|
§ page.team.tasks.pr: Merge date
|
||||||
|
§ page.team.tasks.prAuthor: Merged by user
|
||||||
|
§ page.team.tasks.prDelayDays: Delay before merge in days
|
||||||
|
§ page.team.tasks.comments: Comments
|
||||||
|
§ page.person.print.photo.title: Photo
|
||||||
|
§ page.person.print.photo.description: space for a photo
|
||||||
|
§ page.person.total.title: Main characteristics
|
||||||
|
§ page.person.total.daysWorked.title: days of work
|
||||||
|
§ page.person.total.daysWorked.description: Only days with commits are counted
|
||||||
|
§ page.person.total.tasks.title: tasks
|
||||||
|
§ page.person.total.tasks.description: If commits are properly signed
|
||||||
|
§ page.person.character.title: Character
|
||||||
|
§ page.person.achievement.title: Achievements
|
||||||
|
§ page.person.achievement.positive: Positive
|
||||||
|
§ page.person.achievement.normal: Neutral
|
||||||
|
§ page.person.achievement.negative: Negative
|
||||||
|
§ page.person.achievement.description: The more negative achievements an employee accumulates, the higher the likelihood that the situation is unusual. It may be necessary to change their work mode, tasks, or reporting. A discussion with them to understand what problems are hindering their work is advisable.
|
||||||
|
§ page.person.gets.title: Gets taken:
|
||||||
|
§ page.person.gets.description: "Taking a get" in this context means being the first to leave a commit on a task with a "nice" number.
|
||||||
|
§ page.person.business.days.title: days of work
|
||||||
|
§ page.person.business.days.description: Only days with commits are counted
|
||||||
|
§ page.person.business.tasks.title: tasks
|
||||||
|
§ page.person.business.tasks.description: If commits are properly signed
|
||||||
|
§ page.person.business.losses.title: days without commits
|
||||||
|
§ page.person.business.losses.description: All days minus: holidays, weekends, vacation, days with commits
|
||||||
|
§ page.person.business.commits.title: commits
|
||||||
|
§ page.person.business.commits.description: Deleted branches are not counted
|
||||||
|
§ page.person.business.time.description: Time from the first to the last commit (including non-working days)
|
||||||
|
§ page.person.business.time.title: Days on the project:
|
||||||
|
§ page.person.business.time.dismissed: (dismissed)
|
||||||
|
§ page.person.business.time.staff: (not in the team)
|
||||||
|
§ page.person.business.achievements: Achievements
|
||||||
|
§ page.person.changes.title: Achievements
|
||||||
|
§ page.person.changes.description:
|
||||||
|
With some types of formatting, git marks lines as "deleted" and "added",
|
||||||
|
although in reality, they were "changed". Therefore, if you conducted a major refactoring,
|
||||||
|
git might show a small number of changes in the statistics, but the actual result
|
||||||
|
will be marked as a jump in "deleted" and "added" lines.
|
||||||
|
§ page.person.changes.description: List of commits and the number of changes in them for that day:
|
||||||
|
§ page.person.commits.title: List of commits:
|
||||||
|
§ page.person.money.title.total: Total over time
|
||||||
|
§ page.person.money.title.middle: Average cost
|
||||||
|
§ page.person.money.moneyAll.title: received
|
||||||
|
§ page.person.money.moneyAll.description: Assumed total salary from the project (see settings)
|
||||||
|
§ page.person.money.moneyWorked.title: worked for
|
||||||
|
§ page.person.money.moneyWorked.description: Actual days worked multiplied by average salary
|
||||||
|
§ page.person.money.moneyLosses.title: possible overpayment
|
||||||
|
§ page.person.money.moneyLosses.description: Days without commits multiplied by average salary
|
||||||
|
§ page.person.money.tasks.title: task
|
||||||
|
§ page.person.money.tasks.description: Number of closed tasks to the cost of the day
|
||||||
|
§ page.person.money.commits.title: commit
|
||||||
|
§ page.person.money.commits.description: Number of commits to the cost of the workday
|
||||||
|
§ page.person.speed.task: One task on average is
|
||||||
|
§ page.person.speed.max: Maximum speed per day
|
||||||
|
§ page.person.speed.days.title: days
|
||||||
|
§ page.person.speed.days.description: Refers to workdays, if commits are properly signed
|
||||||
|
§ page.person.speed.commits.title: commits
|
||||||
|
§ page.person.speed.commits.description: Top and bottom 10% of values are trimmed
|
||||||
|
§ page.person.speed.line.title: lines of code
|
||||||
|
§ page.person.speed.line.description: Top and bottom 10% of values are trimmed
|
||||||
|
§ page.person.speed.tasks.title: tasks
|
||||||
|
§ page.person.speed.tasks.description: A task may not be completed, but work should be done on it
|
||||||
|
§ page.person.speed.maxCommits.title: commits
|
||||||
|
§ page.person.speed.maxCommits.description: A task may not be completed, but work should be done on it
|
||||||
|
§ page.person.hours.title: Distribution of commits during each day of the week
|
||||||
|
§ page.person.week.date: Date
|
||||||
|
§ page.person.week.tasks: Number of tasks
|
||||||
|
§ page.person.week.workDays: Days with commits
|
||||||
|
§ page.person.week.taskInDay: Tasks per day
|
||||||
|
§ page.person.week.days: days
|
||||||
|
§ page.person.week.workDay: weekdays
|
||||||
|
§ page.person.week.weekends: weekends
|
||||||
|
`;
|
504
src/ts/translations/zh/recommendations.ts
Normal file
504
src/ts/translations/zh/recommendations.ts
Normal file
|
@ -0,0 +1,504 @@
|
||||||
|
export default `
|
||||||
|
§ recommendations.modal.cancel: Ok
|
||||||
|
§ recommendations.title
|
||||||
|
Recommendations and Facts
|
||||||
|
|
||||||
|
§ recommendations.timestamp.firstCommit.description
|
||||||
|
made the first commit
|
||||||
|
|
||||||
|
Day of the Week: $1
|
||||||
|
|
||||||
|
§ recommendations.timestamp.lastCommit.description
|
||||||
|
made the last commit
|
||||||
|
|
||||||
|
Day of the Week: $1
|
||||||
|
|
||||||
|
§ recommendations.timestamp.common.title: $1 days
|
||||||
|
§ recommendations.timestamp.allDays.description: from the first to the last commit (including weekends and holidays).
|
||||||
|
§ recommendations.timestamp.lossesDays.description: days without commits, even considering weekends, vacation, and public holidays.
|
||||||
|
§ recommendations.timestamp.weekendDays.description
|
||||||
|
working on weekends
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- employees burn out faster;
|
||||||
|
|
||||||
|
§ recommendations.timestamp.regularWeekendWord.title: Regular Overtime
|
||||||
|
§ recommendations.timestamp.sometimeWeekendWord.title: Occasional Overtime
|
||||||
|
§ recommendations.timestamp.weekendWord.description
|
||||||
|
It might be advisable to change the project manager, analyst, and architect.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- the quality of the product is usually low;
|
||||||
|
- some employees resign;
|
||||||
|
- new errors emerge due to the rush;
|
||||||
|
|
||||||
|
# Most likely:
|
||||||
|
- deadlines were incorrectly estimated at the beginning;
|
||||||
|
- technical specifications are missing;
|
||||||
|
- weak analytics;
|
||||||
|
- weak architecture (no architect was hired, and the team consists of mid-level developers);
|
||||||
|
- started writing code first, then planning;
|
||||||
|
- lack of proper processes to understand mistakes;
|
||||||
|
|
||||||
|
§ recommendations.timestamp.neverWeekendWord.title: Usually Without Overtime
|
||||||
|
§ recommendations.timestamp.neverWeekendWord.description
|
||||||
|
But sometimes it happens.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- the client pays double the price for work on a weekend day;
|
||||||
|
- employees burn out faster;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.not.title
|
||||||
|
No Parallel Work
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.not.description
|
||||||
|
any feature at any given time is done by one person.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is less than 1.3, we consider that there is usually no parallel work within most features;
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- increases bus factor;
|
||||||
|
- employees develop more slowly;
|
||||||
|
- difficult to properly check an employee's work;
|
||||||
|
|
||||||
|
# Why this is good:
|
||||||
|
- experts emerge who are deeply immersed in the subject area and can offer more quality solutions;
|
||||||
|
- most likely there are no merge conflicts;
|
||||||
|
- the project can quickly develop in different directions simultaneously;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.has.title
|
||||||
|
Some Work Done in Parallel
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.has.description
|
||||||
|
Sometimes a feature is worked on simultaneously by several people.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is from 1.3 to 2.0, we consider that some of the work within different features is sometimes done in parallel;
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.every.title
|
||||||
|
Parallel Work
|
||||||
|
|
||||||
|
§ recommendations.scope.parallelism.every.description
|
||||||
|
any feature at any given time is worked on by several people
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days are divided by the actual days for each feature;
|
||||||
|
- we find the arithmetic mean;
|
||||||
|
- if the result is more than two, we consider that most of the work within different features is usually done in parallel;
|
||||||
|
|
||||||
|
§ recommendations.scope.money
|
||||||
|
this is the estimated cost for the work on this project.
|
||||||
|
|
||||||
|
# Calculation method:
|
||||||
|
- person-days spent on development are multiplied by the individual salaries of the developers;
|
||||||
|
|
||||||
|
To change the salary of each developer for a more accurate total, go to the "Settings" section.
|
||||||
|
|
||||||
|
# Is this too much or too little?
|
||||||
|
To answer this question, consider the following:
|
||||||
|
- Could a ready-made solution have been purchased for this amount of money?
|
||||||
|
- Could a better product have been developed for this amount of money?
|
||||||
|
|
||||||
|
If the answer to both questions is "yes," then perhaps developing from scratch was not worth the money spent.
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.everyHasOne.title
|
||||||
|
Bus factor = 1
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.everyHasOne.description
|
||||||
|
Most features are deeply understood by only one person.
|
||||||
|
It's necessary to rotate people.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- if employees resign, it will be difficult to continue their work;
|
||||||
|
- it’s impossible to control the quality of their code;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- more than 80% of commits in a feature are made by one person;
|
||||||
|
- the project has more than 60% of such features;
|
||||||
|
|
||||||
|
§ recommendations.scope.bus.oneMaintainer
|
||||||
|
one person is deeply involved in a feature.
|
||||||
|
|
||||||
|
# Why this is bad:
|
||||||
|
- if they resign, it will be hard to continue development;
|
||||||
|
- the quality of code-review decreases;
|
||||||
|
- it’s difficult to parallelize development when needed;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- more than 80% of commits in a feature are made by one person;
|
||||||
|
|
||||||
|
§ recommendations.scope.types.process.title
|
||||||
|
Poor Processes
|
||||||
|
|
||||||
|
§ recommendations.scope.types.process.description
|
||||||
|
Most features contain one type of task.
|
||||||
|
|
||||||
|
§ recommendations.scope.types.one
|
||||||
|
features contain one type of task.
|
||||||
|
|
||||||
|
§ recommendations.scope.types.common
|
||||||
|
It's possible that developers are incorrectly signing commits or the manager is entering the same type of tasks.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- it's impossible to hand over support to another team;
|
||||||
|
- it's impossible to release a "boxed" version;
|
||||||
|
- strong dependence on specific developers;
|
||||||
|
- a high number of errors and low code quality;
|
||||||
|
- potential slowdown in development in the future;
|
||||||
|
|
||||||
|
# The manager's mistake:
|
||||||
|
- viewing the product only from the perspective of a "working demo";
|
||||||
|
|
||||||
|
# What should be done:
|
||||||
|
- tests;
|
||||||
|
- bugs (identified through testing);
|
||||||
|
- refactoring (as architecture may change);
|
||||||
|
- documentation;
|
||||||
|
- style revisions (as a result of focus group feedback);
|
||||||
|
|
||||||
|
§ recommendations.scope.plan.title
|
||||||
|
Develop a Long-Term Plan
|
||||||
|
|
||||||
|
§ recommendations.scope.plan.description
|
||||||
|
taking architecture into account.
|
||||||
|
|
||||||
|
This plan should immediately focus on the most challenging tasks.
|
||||||
|
|
||||||
|
# Why the lack of a plan is bad:
|
||||||
|
- employees create a minimally viable version without planning for expansion points. After this, unscalable code is written, which slows down future features;
|
||||||
|
|
||||||
|
# The manager's mistake:
|
||||||
|
- they haven't shown how the product will develop further and where the growth points will be;
|
||||||
|
|
||||||
|
# How it should be done:
|
||||||
|
- a global product development plan is created;
|
||||||
|
- a global architecture development plan is created (with developers and DBAs);
|
||||||
|
- potential significant changes are discussed upfront at the schematic level;
|
||||||
|
|
||||||
|
§ recommendations.scope.cost.title
|
||||||
|
Evaluate Investment in a Feature
|
||||||
|
|
||||||
|
§ recommendations.scope.cost.description
|
||||||
|
in terms of potential profit.
|
||||||
|
|
||||||
|
Features that are expensive to develop but bring little profit may need to be postponed or even canceled. This will make the project more commercially successful.
|
||||||
|
|
||||||
|
§ recommendations.author.lotOfLazy
|
||||||
|
writes too little code.
|
||||||
|
|
||||||
|
# Should they be fired?
|
||||||
|
- are they a team leader, architect, or analyst?
|
||||||
|
- is this their primary project?
|
||||||
|
- are there any dependencies on them?
|
||||||
|
|
||||||
|
# Why it makes no sense to correct
|
||||||
|
The total costs for the developer are already more than the profit from their work.
|
||||||
|
If we believe that there were no objective hindrances to their work, then the person either does not want to work at all or is working on two projects simultaneously.
|
||||||
|
Firing and replacing them with a new employee seems justified from a statistical point of view.
|
||||||
|
|
||||||
|
§ recommendations.author.manyLazy
|
||||||
|
writes little code. Needs to be monitored.
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- in test samples, a good programmer writes code for more than 80% of the time;
|
||||||
|
- in this case, the indicator is between 60% and 80%;
|
||||||
|
|
||||||
|
# How to monitor:
|
||||||
|
- break tasks into 1..2 days;
|
||||||
|
- ask for a status update every day;
|
||||||
|
- ensure tasks are well defined and ready for development;
|
||||||
|
- arrange pair programming to check actual speed;
|
||||||
|
|
||||||
|
§ recommendations.author.oneTypeMans
|
||||||
|
receives too many monotonous tasks of the same type. Risk of burnout.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- if an employee burns out, their work speed will decrease;
|
||||||
|
- professional growth slows down;
|
||||||
|
- the likelihood of resignation increases;
|
||||||
|
|
||||||
|
# How the sample is chosen:
|
||||||
|
- the type of task is determined for each commit;
|
||||||
|
- if more than 70% of tasks are of the same type, it means the person is doing the same thing repeatedly;
|
||||||
|
|
||||||
|
§ recommendations.author.workToday.title: Working $1
|
||||||
|
§ recommendations.author.workToday.description
|
||||||
|
on the project at this moment.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- more than 50% of workdays;
|
||||||
|
- have worked during the last 30 days;
|
||||||
|
|
||||||
|
§ recommendations.author.dismissed.title: Dismissed $1
|
||||||
|
§ recommendations.author.dismissed.description
|
||||||
|
or worked for a short period.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- worked at a normal pace (apparently, this is their main repository);
|
||||||
|
- no commits in the last month;
|
||||||
|
- vacation usually lasts 14 days (their absence does not resemble a vacation);
|
||||||
|
|
||||||
|
§ recommendations.author.staff.title: Assisting $1
|
||||||
|
§ recommendations.author.staff.description
|
||||||
|
People of other specializations who have committed something.
|
||||||
|
|
||||||
|
# Composition:
|
||||||
|
- $1;
|
||||||
|
|
||||||
|
# Why specifically them:
|
||||||
|
- this is not an open-source project;
|
||||||
|
- workdays less than 15% of the total number;
|
||||||
|
- modify roughly the same files;
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.openSource.title
|
||||||
|
Open Project
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.openSource.description
|
||||||
|
they do not work five days a week here.
|
||||||
|
|
||||||
|
The project may be closed, but this work pace is typical for open libraries on GitHub.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- statistics are taken for all active developers;
|
||||||
|
- the average number of working days and days without commits is calculated;
|
||||||
|
- for open-source libraries, working days are usually a maximum of 15..20%;
|
||||||
|
|
||||||
|
# Consequences
|
||||||
|
For projects where work is not constant, many indicators do not make sense. Therefore, indicators like days without commits, speed, etc., will be hidden.
|
||||||
|
|
||||||
|
Typically, such projects are assessed before starting the development of their own closed version. The most interesting indicators in this case are the probable cost and total development time.
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.easy.title
|
||||||
|
Light Workload
|
||||||
|
|
||||||
|
§ recommendations.author.projectType.easy.description
|
||||||
|
too many days without commits. It is necessary to understand why the team is not writing code.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- take statistics from all active developers;
|
||||||
|
- calculate the average number of working days and days without commits;
|
||||||
|
- workload is considered light if the percentage of days without commits is between 5% and 20%;
|
||||||
|
|
||||||
|
# Possible reasons:
|
||||||
|
- there are actually no tasks;
|
||||||
|
- there are tasks, but they fit well with the current architecture;
|
||||||
|
- developers are distracted by meetings;
|
||||||
|
- the team is not working;
|
||||||
|
|
||||||
|
# Solutions:
|
||||||
|
- discuss the issue with the team;
|
||||||
|
- reduce task granularity so that one or two tasks can be completed in a day;
|
||||||
|
- introduce daily meetings to check the status of tasks;
|
||||||
|
- arrange pair programming sessions to ensure that the developer can work faster;
|
||||||
|
|
||||||
|
§ recommendations.author.manager.title
|
||||||
|
Set Deadlines
|
||||||
|
|
||||||
|
§ recommendations.author.manager.description
|
||||||
|
Every task should have a clear deadline.
|
||||||
|
|
||||||
|
This will prevent dragging out its completion for several days or weeks.
|
||||||
|
|
||||||
|
# Indicators to check:
|
||||||
|
- the number of days spent on one task by an employee;
|
||||||
|
- the number of days waiting for PR merge (PR statistics page);
|
||||||
|
|
||||||
|
§ recommendations.author.shorTalk.title
|
||||||
|
Conduct Daily Meetings
|
||||||
|
|
||||||
|
§ recommendations.author.shorTalk.description
|
||||||
|
they help stay informed about the project.
|
||||||
|
|
||||||
|
Do not stretch them by getting sidetracked on irrelevant topics.
|
||||||
|
|
||||||
|
# Questions the employee should answer:
|
||||||
|
- what was done;
|
||||||
|
- what will be done;
|
||||||
|
- are there any issues;
|
||||||
|
|
||||||
|
# Interruptions should occur if:
|
||||||
|
- they start describing minor details in-depth, which are not important;
|
||||||
|
- they steer the conversation away from the original plan;
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
Often an employee who does nothing tries to avoid the answer by telling a bunch of unnecessary details of their work. This lulls the participants' attention and stretches the time for a response. It creates an impression that they are busy, even though there was no actual work done.
|
||||||
|
|
||||||
|
§ recommendations.author.ipr.title
|
||||||
|
Develop a Training Plan
|
||||||
|
|
||||||
|
§ recommendations.author.ipr.description
|
||||||
|
for each employee.
|
||||||
|
|
||||||
|
*Individual training plan* is a list of goals and tasks that help a person develop in a certain area.
|
||||||
|
|
||||||
|
# How to create a plan:
|
||||||
|
- create a competency matrix;
|
||||||
|
- identify which competencies have the least knowledge and experience;
|
||||||
|
- find out which of these competencies are of interest to the employee;
|
||||||
|
- come up with 3..5 goals within each such competency for the next six months or a year;
|
||||||
|
- try to do something every month to achieve one goal;
|
||||||
|
- remind every month about the overall plan to achieve these goals;
|
||||||
|
|
||||||
|
# Does a manager need a plan?
|
||||||
|
Yes, the manager should also make a plan for themselves. If there is no higher-level manager, they should self-assess.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- employees become more loyal to the company;
|
||||||
|
- you get more qualified personnel for the same money;
|
||||||
|
|
||||||
|
§ recommendations.author.oneToOne.title
|
||||||
|
Conduct One-on-One Meetings Every Month
|
||||||
|
|
||||||
|
§ recommendations.author.oneToOne.description
|
||||||
|
it helps to identify problems at an early stage.
|
||||||
|
|
||||||
|
*One-to-one* is a regular personal meeting of a manager with a subordinate. Such meetings typically discuss everything important to the employee, what concerns them, and what they can share with the manager in private.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- easy to find out who is overburdened and who has free time;
|
||||||
|
- possible to prevent employee burnout;
|
||||||
|
- quick feedback can be obtained about processes that you might not notice;
|
||||||
|
- trust is built, making employees more loyal to the company;
|
||||||
|
- increases employee motivation and engagement;
|
||||||
|
|
||||||
|
§ recommendations.author.club.title
|
||||||
|
Go to a Bar
|
||||||
|
|
||||||
|
§ recommendations.author.club.description
|
||||||
|
once a month or two.
|
||||||
|
|
||||||
|
This will help build informal communication within the team and bring the team together, even if the interaction is brief.
|
||||||
|
|
||||||
|
# Why this is important:
|
||||||
|
- quick feedback can be obtained about processes that you might not notice;
|
||||||
|
- trust is built, making employees more loyal to the company;
|
||||||
|
- increases employee engagement;
|
||||||
|
|
||||||
|
§ recommendations.hour.onlyWork.title: No Weekends Here
|
||||||
|
§ recommendations.hour.onlyWork.description: The project manager should probably be fired.
|
||||||
|
§ recommendations.hour.weekends.title: Working on Weekends
|
||||||
|
§ recommendations.hour.weekends.description: The project manager should probably be checked.
|
||||||
|
§ recommendations.hour.easy.title: There Are Problems
|
||||||
|
§ recommendations.hour.easy.description: There are likely crunch times and work is needed on weekends.
|
||||||
|
§ recommendations.week.lazyDays.down.title: Fewer Absences
|
||||||
|
§ recommendations.week.lazyDays.down.description: this indicator has dropped over the last three weeks
|
||||||
|
§ recommendations.week.lazyDays.up.title: More Absences
|
||||||
|
§ recommendations.week.lazyDays.up.description: no tasks or stricter control is needed
|
||||||
|
§ recommendations.week.notWork.title: Consistently Underperforms
|
||||||
|
§ recommendations.week.notWork.description: as every week the code is not 100% of the time
|
||||||
|
§ recommendations.week.upWork.title: Consistently Overworks
|
||||||
|
§ recommendations.week.upWork.description: as every week code is written on weekend days
|
||||||
|
§ recommendations.week.task.up.title: Productivity is growing
|
||||||
|
§ recommendations.week.task.up.description: or tasks have become too small. Need to check. If granularity is the same - reinforce the result.
|
||||||
|
§ recommendations.week.task.lazyMaintainer.description: consistently leads in absences. Fire?
|
||||||
|
§ recommendations.week.task.down.title: Productivity is Falling
|
||||||
|
§ recommendations.week.task.down.description
|
||||||
|
or tasks are poorly split. Need to check. If granularity is the same - take control.
|
||||||
|
|
||||||
|
# Assessment method:
|
||||||
|
- the number of tasks per day that are being worked on has been steadily decreasing over the last three weeks.
|
||||||
|
|
||||||
|
# Possible errors:
|
||||||
|
- tasks could have been more complex than they seemed;
|
||||||
|
- tasks could have had a large volume of work (need to check if the number of changes is also decreasing during this period)
|
||||||
|
|
||||||
|
§ recommendations.type.everyHasOne.title: Not Signing Task Types
|
||||||
|
§ recommendations.type.everyHasOne.description: Most task types are done by one person.
|
||||||
|
§ recommendations.type.oneMaintainer.title: Narrow Specialization
|
||||||
|
§ recommendations.type.oneMaintainer.description
|
||||||
|
most tasks of one type are done by the same people.
|
||||||
|
|
||||||
|
# Task types:
|
||||||
|
|
||||||
|
§ recommendations.type.common
|
||||||
|
# It might not be the case
|
||||||
|
|
||||||
|
Make sure that other employees correctly sign commits.
|
||||||
|
|
||||||
|
Steps to ensure this:
|
||||||
|
- set up a pre-commit check for commit messages;
|
||||||
|
- explain to the team the need to indicate the type;
|
||||||
|
- check in new branches that employees follow this rule;
|
||||||
|
|
||||||
|
# If it is indeed the case
|
||||||
|
|
||||||
|
You have set up checks and ensured that the same employee does tasks of the same type.
|
||||||
|
|
||||||
|
Why this is bad:
|
||||||
|
- their resignation will halt a whole bunch of processes;
|
||||||
|
- it reduces the competence of other team members;
|
||||||
|
- difficult to understand their edits at a higher level;
|
||||||
|
|
||||||
|
How to fix this:
|
||||||
|
- distribute different types of tasks evenly;
|
||||||
|
- change the area of work (tests, documentation, bugs) among employees every sprint;
|
||||||
|
|
||||||
|
§ recommendations.type.fewTypes.title
|
||||||
|
This is a Local Product
|
||||||
|
|
||||||
|
§ recommendations.type.fewTypes.description
|
||||||
|
for a specific customer or problem.
|
||||||
|
|
||||||
|
# Signs of a "global" product:
|
||||||
|
- localization;
|
||||||
|
- documentation;
|
||||||
|
- a large volume of tests;
|
||||||
|
- visual customization;
|
||||||
|
- refactoring of bottlenecks;
|
||||||
|
- etc.
|
||||||
|
|
||||||
|
# Why this product looks like a "local" one:
|
||||||
|
- each "global" sign will be outweighed by its type of task;
|
||||||
|
- the more "global" signs, the more likely a "global" product;
|
||||||
|
|
||||||
|
In this case, we see a small number of types, which likely indicates shortcomings that prevent the product from being easily scaled to the global market and sold in other countries.
|
||||||
|
|
||||||
|
# It might not be the case
|
||||||
|
Based on file types, we can assume the type of program (website, server application, DevOps scripts, etc.). For a frontend application, our hypothesis will be more accurate than for DevOps scripts, which might just be a micro-module of initialization.
|
||||||
|
|
||||||
|
§ recommendations.type.diff.title
|
||||||
|
Break Down the Leading Type into Subtypes
|
||||||
|
|
||||||
|
§ recommendations.type.diff.description
|
||||||
|
to detail errors.
|
||||||
|
|
||||||
|
Typically, the task type labeled "bug fixing" is leading. This makes the statistics weakly detailed.
|
||||||
|
|
||||||
|
*If you encounter this situation*, you can break down this type into subtypes (e.g., based on the location of detection).
|
||||||
|
|
||||||
|
Consider several options for subtypes:
|
||||||
|
- fix_dev (error detected during development);
|
||||||
|
- fix_test (error detected during testing);
|
||||||
|
- fix (error detected in production);
|
||||||
|
|
||||||
|
§ recommendations.type.buddy.title
|
||||||
|
Accumulate Minor Tasks
|
||||||
|
|
||||||
|
§ recommendations.type.buddy.description
|
||||||
|
for new employees.
|
||||||
|
|
||||||
|
# If a task is:
|
||||||
|
- not important;
|
||||||
|
- not big;
|
||||||
|
- doesn't require deep immersion in the context;
|
||||||
|
- more about refactoring than new code;
|
||||||
|
|
||||||
|
# Put it in the backlog with the label "for beginners".
|
||||||
|
|
||||||
|
When a new employee arrives, you will be able to immediately pull out a bunch of small and varied tasks for them to get acquainted with the project.
|
||||||
|
|
||||||
|
Also, if you have a lull in work, you can pull out one such minor task from the backlog.
|
||||||
|
`;
|
27
src/ts/translations/zh/settings.ts
Normal file
27
src/ts/translations/zh/settings.ts
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
export default `
|
||||||
|
§ page.settings.document.title: Display settings
|
||||||
|
§ page.settings.document.name: Page title
|
||||||
|
§ page.settings.document.language: Interface language
|
||||||
|
§ page.settings.links.title: Link prefixes
|
||||||
|
§ page.settings.links.task: For task numbers
|
||||||
|
§ page.settings.links.pr: For PR
|
||||||
|
§ page.settings.user.title: Individual settings
|
||||||
|
§ page.settings.user.notFound: No individual settings. Data for all employees are calculated based on common parameters.
|
||||||
|
§ page.settings.user.subTitle: Addendum to employment contract №$1
|
||||||
|
§ page.settings.user.from: Start date
|
||||||
|
§ page.settings.mailmap: .mailmap example
|
||||||
|
§ page.settings.common.title: General salary data
|
||||||
|
§ page.settings.common.type.title: Project work type
|
||||||
|
§ page.settings.common.type.full: Full-time employment
|
||||||
|
§ page.settings.common.type.part: Project work
|
||||||
|
§ page.settings.common.salary: Monthly salary
|
||||||
|
§ page.settings.common.currency: Currency
|
||||||
|
§ page.settings.common.workDaysInYear: Number of working days in a year
|
||||||
|
§ page.settings.common.vacationDaysInYear: Number of vacation days in a year
|
||||||
|
§ page.settings.common.workDaysInWeek: Workdays
|
||||||
|
§ page.settings.form.save: Save
|
||||||
|
§ page.settings.form.cancel: Cancel
|
||||||
|
§ page.settings.form.remove: Remove
|
||||||
|
§ page.settings.form.addEmployee: Add an employee
|
||||||
|
§ page.settings.form.addContract: Add an employment contract
|
||||||
|
`;
|
Loading…
Reference in a new issue