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 |