The first step in this is to make sure that the subject completely designs team fedora.
A second step is to check the validity according to legal terms.
In this category are the rules established by the international community and the team's fedora.
The process seems simple but requires time and cooperation.
Let's see some example:
Example 1: The python logo can be used according to the python official website:
The Python Logo Projects and companies that use Python are encouraged to incorporate the Python logo on their websites, brochures, packaging, and elsewhere to indicate suitability for use with Python or implementation in Python. Use of the "two snakes" logo element alone, without the accompanying wordmark, is permitted on the same terms as the combined logo.
Example 2: The Fedora logo usage:
These are the official brand and logo usage guidelines for Fedora. Usage of Fedora and related logos must follow the guidelines as specified below. All users must also comply with the official trademark guidelines.
Trac has a built in small and powerful wiki rendering engine and used Wiki markup to fill your issues.
You can add files to your ticket and used comments to solve it.
Now the Fedora design team used
trac.
The official webpage told us about
trac:
Trac is a web-based software project management and bug/issue tracking system emphasizing ease of use and low ceremony. It provides an integrated Wiki, an interface to version control systems, and a number of convenient ways to stay on top of events and changes within a project. Trac is distributed under the modified BSD License. The complete text of the license can be found online as well as in the COPYING file included in the distribution.
When you open a new ticket you need to fill with all info and data to make it to make it solvable.
Also, it would better to be discussed in team meetings fedora design because this will brainstorms ideas and will avoid comments or any inconsistency with another ticket or usage of output. When you used to open the new ticket then you may use
WikiFormatting .
The new
Create New Ticket comes with some field:
Properties - all about this ticket:
Summary - is more like a title, and is a little summary of the ticket.
Description - is the description of the ticket and has at least three components completed in order
to facilitate the work will solve the ticket and come with the three components:
= phenomenon =
= reason =
= recommendation =
The type - is the type of ticket and this will put into the area of interest and that will show us the interaction with the understanding of which will be part of the final component will be.
Type:
- Design and Tools Education
- Digital Artwork;
- Print/Swag Design;
- Release Artwork;
- UX/Interaction Research and Design;
- Web Design;
- Team Maintenance;
Priority - will determine the team needs intervention and is four:
release blocker
high
medium
low
Severity - represent the complexity in solving this ticket
- Quick & Easy
- Moderately Involved
- Long-Term / Complex Issue
Keywords -
the unused part but that could solve many problems in the management of packets, logo, banner, wallpaper, badget, foss, devel-team, infra-team
Cc - indicates those who are to receive a copy
The next edit box is used for the owner, blocking issue and put to work:
Blocked By,
Blocking and
Owner.
The next step is resolving proper, comments remediation work and finally, upload the ticket closure.
Although it seems simple in real completing the final result emerges by differentiation with similar components in the online environment in terms of the one he sees and the one working in similar areas of design.
My point: The best results are obtained not through cooperation at operational management. They appear as the sum of the factors involved in platforms and solutions implemented for the design team members. Therefore their knowledge is very useful.
