Projekt

Obecné

Profil

Conventions and Guidelines » Historie » Verze 2

Eliška Mourycová, 2021-04-17 20:04

1 1 Eliška Mourycová
h1. Conventions and Guidelines (WIP)
2
3
h2. Issue Management
4
5 2 Eliška Mourycová
h3. Issue Trackers
6 1 Eliška Mourycová
7 2 Eliška Mourycová
* Bug
8
Use this tracker when the issue references a known bug that needs to be fixed.
9
* Enhancement
10
???
11
* Task
12
Use this tracker for issues related to implementation of a designed/analyzed part of the system.
13
* Support
14
Use this tracker for issues related to non-implementation task, e.g. any meeting issues, wiki editing, ...
15
* Feature
16
???
17
18
h3. Logging Time
19
20
When logging time for an issue, always(????) write a short comment, even if it's a duplicate of the issue's subject, but if it's possible, try to be more specific.
21
22
h4. Activity for Time Logging
23
24
* Unspecified
25
Do not use this activity.
26
* Analysis
27
Use this activity, when you're logging time for anything analytical, for example research/interface design/... ???
28
* Design
29
???
30
* Implementation
31
Use this activity, when you're logging time for implementing (coding) anything
32
* Verification
33
???
34
* Documentation
35
Use this activity, when you're logging time for creating/editing some documentation for exaplmple in some wiki page(s)
36
* Administrative
37
Use this activity for meetings
38
39
40
If the work you did matches more than one of the activities, either log time separately or choose such activity you spent most time doing.
41
42
43
44 1 Eliška Mourycová
h2. Code Contributions (Commits)
45
46
h3. Linking Commits to Issues
47
48
* Every commit must be linked to an issue, i.e. in each commit use the key word Re #<issue-no>. Alternatively, you can use the key word refs #<issue1-no>, #<issue2-no>, although it is preferable for each commit to be linked with exaclty one issue.
49
* If you think your commit is not related to any existing issue, link it to the "Refactoring" issue (such issue will be prepared for every iteration).
50
* It is preferable for the keyword(s) to appear at the very beginning of a commit message. ??????
51
chceme i jiny nez re a refs ???????
52
53
Note.: The keywords are caseinsensitive and at least one blankspace or colon is needed between the keyword and the first hash to produce a match (taken from Redmine doc).
54
55
h3. Commit messages
56
57
Every commit must have a commit message briefly explaining what the changes in the commit do.
58
59
60
h3. End of Iteration tags
61 2 Eliška Mourycová
62 1 Eliška Mourycová
????
63
64
65
h2. Coding and Code Documentation
66
67 2 Eliška Mourycová
When coding, use the generally known best practices (whether they concern the used language or not), see some of the coding conventions for C# at https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions.
68 1 Eliška Mourycová
69
* Use reasonable variable names
70
* Comment the code
71
> * Use documentation comments for classes and methods (see https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/documentation-comments)
72
> * Use in-code comments too - the rules for this aren't strict, but try to comment every line/block of code, which might be even a little unclear to the reader
73 2 Eliška Mourycová
* Sign each file you create (at the beginning of the file add a comment with the following line):
74
"Author: Your Name"
75 1 Eliška Mourycová
76
h2. Wiki Documentation