Kihagyás

Feature Request Template for GitLab

This document provides a comprehensive checklist and guide for creating a feature request issue template in GitLab. It mirrors professional product development practice while helping students learn how to define and communicate new feature ideas clearly.

  1. Create an issue for ech section below in your GitLab repository. For example: "Technical Steps for Creating the Template in GitLab"
  2. Copy the checklist items from each section into the corresponding issues' descriptions.
  3. Start working on implementing the bug report template in your repository. Check off each step as you complete it.

Feature Requests Come from the Team or Customer

Unlike bug reports, feature requests describe something new — an enhancement, missing capability, or usability improvement. Clarity and justification are key.

Technical Steps for Creating the Template in GitLab

1
2
3
4
5
6
- [ ] Create the folder `.gitlab/issue_templates/` in your repository (https://docs.gitlab.com/user/project/description_templates/)
- [ ] Add a new file named `feature_request.md`
- [ ] Add a quick action at the top to label the issue automatically, e.g. `/label ~"feature request"` (https://docs.gitlab.com/user/project/quick_actions/)
- [ ] Commit and push to your main branch
- [ ] Test by opening a new issue and selecting “Feature Request” as the template
- [ ] Refine using the checklist items in each section below

## Summary & Motivation

Briefly describe what you want to add and why it matters.

1
2
3
4
- [ ] Include a placeholder for a **clear, action-oriented title** (e.g. “Add dark mode to dashboard”)
- [ ] Add a short field: “Describe the feature and why it is needed”
- [ ] Include a sentence starter like “This feature will help users…”
- [ ] Optional: link to a related user story, issue, or requirement

## Problem or Use Case

Clarify the situation or need this feature addresses.

1
2
3
- [ ] Add a section titled **Problem / Use Case**
- [ ] Write a guiding line: “Describe the situation where this feature would be used”
- [ ] Include an example: “Users currently cannot export data to CSV, which limits sharing results”

## Proposed Solution

Explain what the new feature would do at a functional level.

1
2
3
4
- [ ] Add a section titled **Proposed Solution**
- [ ] Include a prompt: “Describe how the feature should behave or look”
- [ ] Encourage bullet points for clarity (e.g. “When user clicks Export, show file format options”)
- [ ] Add a note: “Avoid describing exact code — focus on functionality”

## Alternatives Considered

Show that you’ve thought about options and trade-offs.

1
2
3
- [ ] Add a section **Alternatives Considered**
- [ ] Include a prompt: “Have you explored other ways to solve this problem?”
- [ ] Add an example: “We could extend the existing print feature, but that would be slower for large datasets”

## Expected Benefits

Summarize how this feature adds value to users or the project.

1
2
3
- [ ] Add a section titled **Expected Benefits**
- [ ] Include a line: “Explain how this feature improves usability, performance, or satisfaction”
- [ ] Encourage listing tangible impacts (e.g. “Reduces manual work by 50%”)

## Possible Risks or Dependencies

Identify what could go wrong or what depends on it.

1
2
3
- [ ] Add a section **Risks / Dependencies**
- [ ] Include prompts: “What other features or components does this depend on?” and “Any technical or design risks?”
- [ ] Add a reminder: “List any blockers or related issues”

## Acceptance Criteria

Define what must be true for this feature to be considered complete.

1
2
3
4
5
6
- [ ] Add a section titled **Acceptance Criteria**
- [ ] Include a checklist of expected outcomes, for example:
      - [ ] User can enable or disable dark mode from settings
      - [ ] Theme persists across sessions
      - [ ] No layout errors appear
- [ ] Add an instruction: “Be specific but measurable”

## Attachments / References

Support the request with any visual or related materials.

1
2
3
- [ ] Add a section **Attachments / References**
- [ ] Include: “Attach mockups, sketches, screenshots, or related links”
- [ ] Add a reminder to credit or link any external design inspirations

## Priority & Responsibility

Mark what is not part of the template but decided later by the team.

1
2
- [ ] Add a note: “Assignee, milestone, and priority are set by project management after evaluation”
- [ ] Do not include these as editable fields in the template

## Verification / Testing Plan

Think ahead about how success will be validated.

1
2
3
- [ ] Add a section titled **Verification**
- [ ] Include a prompt: “Describe how to verify the feature works as intended”
- [ ] Provide an example: “Enable dark mode and confirm UI elements adapt correctly across all pages”