Feature Wiki
Tabs
Creating A New Feature Page
Page Overview
[Hide]- 1 Summary
- 2 Problem Statement
- 3 Concept
- 4 User Interface Modifications
- 5 Non-Functional Implications
- 5.1 Security
- 5.2 Privacy
- 5.3 Accessibility Implications
- 6 Process Information
- 6.1 Involved Authorities
- 6.2 Contact
- 6.3 Funding
- 7 Discussion
- 8 Implementation
- 8.1 Description and Screenshots
- 8.2 Test Cases
- 8.3 Privacy
- 8.4 Approval
If you need any help in filling out this wiki page, please have a look at the page ’How To Suggest A New Feature’.
You can remove the editing notes (paragraphs in italics) after having created the request (same with this block).
Please don't forget to complete the metadata (‘Status of Feature’) in the right column after having created the page.
1 Summary
{ Not more than three sentences that capture the essence of what you plan to do. This information shall allow people to decide if they are interested to further engage with this request or not. }
2 Problem Statement
{ This text shall allow people to understand the problem that your request is intended to solve. }
3 Concept
{ This is the heart of the feature request: the concept. The content here shall:
- make it possible to discuss this feature thoroughly on the Jour Fixe and make a decision
- allow operators of ILIAS to understand the impact of this feature on their installations
- allow all contributors to understand the impact of the change on their components and the complete system
So this is not about jumping through hoops, this is a crucial communication task in our software development process.
To help in this effort, we propose to use these guiding questions:
- How will existing functionality look differently after the change?
- How can an existing feature be used differently after the change?
- Which mockups (or even scribbles) will help to understand changes in the user interface?
- Which UI components will need to be introduced or modified?
- How will your Feature Request change an underlying logic of the system or a component?
- Which diagrams, graphs, tables or other forms of visual aid will help to understand that change in logic?
- How will this affect operators or users who are already familiar with and rely on the current version of this feature?
- Which changes might catch operators or users off guard or throw them off track, despite their familiarity with the current version of the feature or system?
- How will this change existing data structures or established workflows?
- How will this affect compatibility to previous ILIAS versions?
- Which components of the system will be involved with or affected by the change?
- Which dependencies to other software will be introduced when implementing this features?
- Which technical specialities are worth considering to understand this change?
- Which risks to the system or its operators are worth considering?
These questions are not meant to be answered one by one, but instead shall help you to create a coherent text that describes your feature. Tell us the story about your idea! }
4 User Interface Modifications
4.1 List of Affected Views
- …
{ For all screens that should be modified, newly introduced or removed, please list the title and breadcrumb of all affected views. }
4.2 User Interface Details
{ For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour. }
4.3 New User Interface Concepts
{ If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this. }
4.4 Technical Aspects
{ Necessary technical information have to be provided here, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }
5 Non-Functional Implications
5.1 Security
{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }
5.2 Privacy
{ Please list here all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. Use the Privacy Guidance for Feature Requests to fill out this section correctly. }
5.3 Accessibility Implications
{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }
6 Process Information
6.1 Involved Authorities
- Authority to Sign off on Conceptual Changes: {Please add related profile link of this person}
- Authority to Sign off Code Changes: {Please add related profile link of this person}
If this request is related to multiple components, please list both authorities for all related components.
6.2 Contact
Person to be contacted in case of questions about the feature or for funding offers: {Please add related profile link of this person}
6.3 Funding
Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.
If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.
7 Discussion
8 Implementation
Feature has been implemented by {Please add related profile link of this person}
8.1 Description and Screenshots
{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }
8.2 Test Cases
Test cases completed at {date} by {user}
- {Test case number linked to Testrail} : {test case title}
8.3 Privacy
Information in privacy.md of component: updated at {date} by {user} | no change required
8.4 Approval
Approved at {date} by {user}.
Last edited: Today, 12:54, Kunkel, Matthias [mkunkel]