Project FAQ
What should I name my project in GitLab?
See project setup for details.
Does it matter which team member “owns” the project?
No. Just make sure that all team members have full access to the project (Manage > Members in the project settings), and that your TA and instructor have at least Developer access.
How do issues relate to requirements?
The requirements that you discussed as part of your project proposal should be addressed by the features that you include. Each feature should be represented by one or more GitLab issues, with the details of how you will implement that feature.
Another way to think about the relationship is that issues are a representation of the tasks required to address the requirements.
Issues is a terrible name for this concept, but it’s the term that GitLab uses (and which is commonly used in industry). You can also think of issues as tasks to be completed, that address your project’s requirements.
How should I structure my issues so that they make sense?
In an ideal system, we could model this relationship as an umbrella of issues (work to be done) grouped under a parent issue (requirement). e.g.,
Unfortunately, GitLab doesn’t support issue hierarchies like this. It’s recommended that instead you create separate issues and link related issues together (using the Link field in the issue).
e.g. a requirement like “Create a user record” might break into multiple linked issues.
What information should I add to my issues? (i.e. what should they contain?)
You should decompose your tasks into half-day “chunks” of functionality that is (a) logically related, and (b) testable. The issue should describe what you need to do to implement this functionality.
e.g. the “Create a user record” example above might decompose into two or more related issues.