Projekt

Obecné

Profil

Conventions and Guidelines » Historie » Verze 14

Alex Konig, 2021-05-03 11:03

1 9 Eliška Mourycová
h1. Conventions and Guidelines
2 1 Eliška Mourycová
3
h2. Issue Management
4
5 5 Eliška Mourycová
h3. Creating/Editing an Issue
6 1 Eliška Mourycová
7 5 Eliška Mourycová
h4. Status
8
9
* *New*
10
Use this status, when you're creating an issue and you don't know, which team member should resolve it, or if the issue concerns the whole team (e.g. team meetings)
11
* *Accepted*
12 14 Alex Konig
Use this status, to distinguish issues in progress from new issues.
13 5 Eliška Mourycová
* *Assigned*
14
Use this status when there is a known assignee for the issue. In such a case, fill in the assignee as well.
15
* *Resolved*
16
Use this status, when you finished working on the issue.
17 10 Roman Kalivoda
* _Invalid_
18
_Use this status when the issue is not going to be worked on._
19 5 Eliška Mourycová
20
h4. Priority
21
22
Available priority levels are:
23
24
* *Low*
25
* *Normal*
26
* *High*
27
* *Urgent*
28
29
Setting a priority other than *Normal* is especially important, when dealing with issues in back log. That is, if an issue was not resolved in a past iteration and the issue needs to be finished as soon as possible, assign *High* or *Urgent* priority to it. If resolving the issue can wait, use *Low* priority. 
30
Also, when an issue is due a date before the end of the iteration, because some other isues depend on it, it should have *High* or *Urgent* priority as well.
31
32
h4. Tracker
33
34 3 Eliška Mourycová
This section explains, which tracker should be used for which type of issue.
35 1 Eliška Mourycová
36 3 Eliška Mourycová
* *Bug*
37 2 Eliška Mourycová
Use this tracker when the issue references a known bug that needs to be fixed.
38 1 Eliška Mourycová
* *Enhancement*
39 11 Roman Kalivoda
Use this tracker for issues related to tasks that were not originally requested. _(Use it for major project tasks, as product backlog?)_
40 1 Eliška Mourycová
* *Task*
41 8 Eliška Mourycová
Use this tracker for "general" issues which only say "something should be done" but could contain within them analysis, implementation and more.
42 1 Eliška Mourycová
* *Support*
43
Use this tracker for issues related to non-implementation task, e.g. any meeting issues, wiki editing, ...
44
* *Feature*
45 11 Roman Kalivoda
Use this tracker for issues related to the implementation of a designed/analyzed part of the system.
46 2 Eliška Mourycová
47 1 Eliška Mourycová
h3. Logging Time
48 3 Eliška Mourycová
49 5 Eliška Mourycová
When logging time for an issue, you should write a short comment, unless the subject of the issue is self-explanatory and the issue is going to be resolved, after you log the time, e.g. logging time for meetings.
50 3 Eliška Mourycová
51 2 Eliška Mourycová
h4. Activity for Time Logging
52 3 Eliška Mourycová
53 1 Eliška Mourycová
* *Unspecified*
54
Do not use this activity.
55
* *Analysis*
56 12 Roman Kalivoda
Use this activity, when you're logging time for anything analytical, for example, research/brainstorming of any kind/...
57 1 Eliška Mourycová
* *Design*
58 12 Roman Kalivoda
Use this activity, when you're logging time for designing something, however, *Analysis* can be used instead.
59 3 Eliška Mourycová
* *Implementation*
60 5 Eliška Mourycová
Use this activity, when you're logging time for implementing (coding) anything.
61 3 Eliška Mourycová
* *Verification*
62 12 Roman Kalivoda
Use this activity, when you're logging time for verifying someone else's work. _(+ testing?)_ 
63 3 Eliška Mourycová
* *Documentation*
64 12 Roman Kalivoda
Use this activity, when you're logging time for creating/editing some documentation for example in some wiki page(s).
65 2 Eliška Mourycová
* *Administrative*
66 13 Eliška Mourycová
Use this activity for meetings and repository management (e.g. merging).
67 1 Eliška Mourycová
68 12 Roman Kalivoda
If the work you did matches more than one of the activities, either log time separately or choose such activity you spent the most time doing.
69 1 Eliška Mourycová
70
h2. Code Contributions (Commits)
71
72
h3. Linking Commits to Issues
73 4 Eliška Mourycová
74
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.
75
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).
76
It is preferable for the keyword(s) to appear at the very beginning of a commit message.
77 1 Eliška Mourycová
You can use other keywords for referencing issues in commit messages, e.g. *closes, fixes, done, fixed* - these keywords also affect the issue itself. It is not required to use these keywords.
78
79
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).
80
81
h3. Commit messages
82
83
Every commit must have a commit message briefly explaining what the changes in the commit do.
84
85
86 3 Eliška Mourycová
h3. End of Iteration Tags
87 1 Eliška Mourycová
88 5 Eliška Mourycová
At the end of every iteration, the team members' work in separate branches should be merged into the master branch. This merge commit should be tagged as the end of iteration.
89 1 Eliška Mourycová
90
91
h2. Coding and Code Documentation
92
93
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.
94
95 3 Eliška Mourycová
96
h3. General Naming Conventions
97
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions
98
99 7 Eliška Mourycová
Choose easily readable identifier names.
100
Favor readability over brevity.
101
Do not use underscores, hyphens, or any other nonalphanumeric characters.
102
Name identifiers in English.
103 3 Eliška Mourycová
104
h3. Capitalization Conventions
105 1 Eliška Mourycová
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions
106
107 4 Eliška Mourycová
Use PascalCasing (i.e. camelCasing with the first character capitalized) for naming the following types of identifiers:
108
* Namespace
109
* Type
110
* Interface
111
* Method
112
* Property
113
* Event
114
* Field
115
* Enum value
116 3 Eliška Mourycová
117 6 Eliška Mourycová
Use camelCasing for parameters.
118
Use ALL_CAPS for constants.
119 1 Eliška Mourycová
120 3 Eliška Mourycová
h3. Code Commenting
121
122 7 Eliška Mourycová
Write all comments in English.
123 4 Eliška Mourycová
Use documentation comments for classes and methods (see https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/documentation-comments)
124
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
125
Sign each file you create (at the beginning of the file add a comment with the following line): "Author: Your Name"
126 3 Eliška Mourycová
127
h2. Wiki Documentation
128 4 Eliška Mourycová
129
On the wiki main page, you can find links to most of the important pages related to the project.
130
On some of the pages, the links to child pages appear in the text - if you struggle to find anything, go to *Index by title* and find the page you are looking for there.
131
Write/edit pages in English.