Krita/Docs/PhabricatorProjectsLayout

From KDE Community Wiki
< Krita‎ | Docs
Revision as of 12:20, 20 June 2016 by Dmitry (talk | contribs)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Krita Phabricator Structure

The main Krita Project should not contain individual tasks. All the current work should be managed by the provided subprojects. Here is the list of available subprojects.

Bugfixes (3.0)

This is the project for managing release cycle of the currently stable Krita release. Right now it is Krita 3.0 and all its minor releases, like 3.0.x.

The project contains lists of bugs that are scheduled for the next minor relesase. These bugs should be already triaged, that is reproducible by at least someone from the Krita Developers Team, and sorted by a priority level (highest priority at the top).

Columns description

  • Backlog — unsorted bug candidates for fixing
  • Needs Info — the bug has been checked/answered by a developer, but it needs more info from the community. It might need some more details, comments or GUI designs. After staying in this column for too long, it might be deleted.
  • Triaged — usual bugs that should be worked on, but not scheduled yet. Preferably, the bug should be reproducible. If not, it will be moved back to Needs Info column. The bugs at the top has higher priority than the ones at the bottom.
  • Planned for Release: Minor — the bug is scheduled for the release, it is reproducible and is quick to fix (in a couple of hours or so)
  • Planned for Release: Critical — the bug is scheduled for the release, it is reproducible but may take a significant amount of time to fix (a day or more)
  • Later — the bug is postponed till the next minor release. The content of this column will be moved to the Triaged field after the next release.


General recommendations

  1. If the bug is really small and easy to fix (< 1 day of work), put it into the Minor column in the order of importance.
  2. If the bug is complex enough, make sure the bug is reproducible (preferably, ask on IRC) and put it into the Critical column.
  3. If there are some bugs in the Needs Info, it might be probable, that someone in the community should be poked to answer additional question. When the question is answered, put the bug back to an appropriate column.

Bug task format

No additional information is needed. Just put (probably, in your own words) the short name of the bug in a title, and put a link to a bugzilla to the content of the bug.

Example: T457

Next Stable (3.1)

Project for managing planned features of the next stable release. That is Krita 3.x. The project contains only the tasks that are planned for exactly the next release. E.g. don't put Vector tools into the project of Krita 3.1.

Columns description

There are four columns for bugs in this workboard on the phabricator.

  • Backlog — unsorted feature candidates which were not started yet. At this stage people can do the brainstorming and add any adeas to the task's comments. See link1 and link2.
  • Needs requirements — the task needs precise requirements for the feature. See link1 or link2
  • Needs GUI design — self-secriptive. People can do the actual discussion in Pholio mockups or anywhere else. A good example of the GUI design can be found here
  • Needs coding well, self-descriptive.
  • Needs documentation
  • Needs twitter the posts in social networks should tell the people about this feature. The list of the networks might include: twitter, tumblr, facebook, google+, vk.

Longterm features

This project contains the features, which are nice to be implemented in Krita, but which are not planned for any release. These feature has no deadlines, and, probably, no assignee. Some of the features might be nice topics as junior-jobs for newcomers.

Columns description

There are four columns for bugs in this workboard on the phabricator.

  • Backlog — unsorted feature candidates which were not started yet. At this stage people can do the brainstorming and add any adeas to the task's comments. See link1 and link2.
  • Needs requirements — the task needs precise requirements for the feature. See link1 or link2
  • Needs GUI design — self-secriptive. People can do the actual discussion in Pholio mockups or anywhere else. A good example of the GUI design can be found here
  • Needs coding well, self-descriptive.
  • Needs documentation
  • Needs twitter the posts in social networks should tell the people about this feature. The list of the networks might include: twitter, tumblr, facebook, google+, vk.

Translations of the Website

This project contains the tasks for the translators teams and for the site maintainer. The maintainer creates the tasks for each of the translation teams, and after they are finished, they move the task to the maintainer's list.

Columns description

  • JP team
  • FR team
  • RU team
  • Site maintainer

General (Abyss)

All the tasks that could not be categorized into any of the projects above, should be assigned to this project.


<Name>'s Workboard (personal projects)

These are the personal projects of the Krita Developers team members. Just in case you need one.