Forgejo design documents

This repository is used for focusing on design work for Forgejo, where design includes

• User Experience
• User Interface (what is commonly understood as "design")
• technical considerations

What you can do here

please do:

• suggest ideas and potential solutions if you want to participate in our design process
• reference evidence or user input that should be considered

please do not:

• request new features (create it here instead)
• comment with your opinion, unless explicitly asked (we want to prevent the noise of comments if users "dislike" what we do here, we want to focus on evidence and solutions instead)

We might apply some strict rules to reduce the noise in this issue tracker. Please don't feel offended if we ask you to change your behaviour. Instead, try to reflect your own and understand our motivation. Unfortunately, this is necessary, because design work is not commonly accepted in the free/libre software communities. In the past, our work was often disrupted by people who either insist on their own opinion, or who simply disagree to our considerations for improvement.

This disrupts our workflows and prevents us from doing what we love. We want to find an optimal solution that addresses user problems in a way that deals sensibly with the constrained human resources for the actual implementation. It might not always be possible to include your favourite idea, though.

The process

Note

This place is pretty new and in the process of establishing itself. Feel free to suggest amendments to the workflows.

Use the issue tracker only for ToDos and discussions. Actual work and outcome should be documented in the Git repository.

We use one folder per design unit (a change in Forgejo that is closely related to each other) and document the state in markdown files.

New work happens in branches. They are reviewed using Pull Requests, and are ready for implementation once merged in the main branch.

All contributors are free to push directly to work branches if the change is all of the following:

• adds ideas and input only
• does not contradict ongoing discussions
• does not permanently remove information

All other changes have to use separate Pull Requests to the work branch.

Why was my issue closed?

Sometimes, we might close issues (mostly feature requests) in Forgejo with a notice refering to this repository. It typically means that we appreciate your input and find it valuable, and have extracted relevant aspects to be included in a future Forgejo version.

However, many "feature requests" are not ready to be implemented as-is. As discussed in the past, many feature requests propose a solution instead of describing the problem. In the spirit of not listening to users (we do listen to your problems, don't worry!), we extract the issues you face and consider if there is a better solution than what you proposed.

Usually, there are multiple feature requests that originate from the same or similar problems. Often, there can be one solution that addresses multiple needs, and we try to understand your issue and find solutions that save the time of our developers, and result in a snappy and consistent user experience in the end.

Such a message typically looks like this:

Hi there! Thank you for describing your problem and / or suggesting improvements to Forgejo.
Most or all relevant aspects of this issue were included in ongoing [Forgejo design work](https://codeberg.org/forgejo/design/) and are considered for future versions. We might close this issue here to reduce the redundancy and focus on actionable issues.

You can [learn more about what this means](https://codeberg.org/forgejo/design#why-was-my-issue-closed)

Gaining privileges

We do not give write permissions by default, but you are free to ask for it in the issue tracker.