Skip to Content
 Русский Русский    English English   


Bug tracking

The bug tracking system give software users possibility to directly report founded errors (usually called bugs) and keep track on their fixing.

You can directly report founded bugs in bug tracking system.



Active - this is the default state of a new issue, but may also sometimes be used for 'resetting' an issue that has gotten off-course even if the issue has old patches attached.

Patch (code needs work) - there is a patch attached to the issue, but the patch needs additional work before it should be reviewed. The author of the patch may indicate that it is incomplete, or the patch has gone through the reviewing process and has received feedback about areas where it needs improvement.

Patch (code needs review) - a patch has been created and needs review and testing. With sufficient positive feedback, the patch may be promoted to the status "Patch (reviewed & tested by the community)". If a reviewer finds a problem with the patch, it will then be marked as "Patch (code needs work)".

Patch (reviewed & tested by the community) - the patch has received a thorough review and test by one or more experienced developers, and they have deemed it as ready to be committed to the project. One should not set one's own patch to this status. Patches need to go through the review process. Some exceptions may be made if another developer voices their support, or when the patch is utterly trivial. If you are unsure, the status should not be changed. Simply add the findings of your review to the issue.

Patch (to be ported) - the patch has been successfully committed to a branch of the project, and still needs to be committed to another, but the current patch doesn't apply to the target branch and needs to be modified in order to do so.

Fixed  -  the issue has been resolved (usually by committing a patch). Issues that remain in this state without any additional comments will automatically be set to "Closed (fixed)" after two weeks. This gives interested parties time to reactivate the issue if they see a problem with the fix and also allows time to see that a change has been made.

Postponed  - that the issue is valid and should be fixed, but postponed  for some reason. May mean either 1) that other related issues need to be dealt with first, or 2) that the issue is removed from current active work but the intent remains to return to it.

Postponed (maintainer needs more info) - there is insufficient information in the issue to proceed. Should no additional information about the issue be provided, the issue may be marked either "Closed (cannot reproduce)"  or "Closed (won't fix)" at the discretion of the reviewer.

Closed (duplicate) - an identical, or strikingly similar issue has already been created. The issue being marked as a duplicate issue should provide a link back to the earlier version of the issue.

Closed (won't fix)  - It has been decided that this issue will not be fixed. This includes feature requests that are deemed to be outside the scope of the project, bug reports that are too far-reaching to fix, etc.

Closed (works as designed)  - the reported issue has been deemed not to be an issue. The reported behavior is either an intentional part of the project, or the issue is caused by manually applied customizations of a user (wrong configuration, code alterations).

Closed (cannot reproduce)  - if no-one is able to reproduce the problem being reported, an issue can be closed with this status. It's possible that the original reporter is confused and "works as designed" might be more accurate, but there's not enough evidence to be sure. If someone else can come along and reproduce the problem, they can provide the information and move it back to "Active". However, if the maintainer says the issue is "Closed (works as designed)", there's no point trying to provide further information or to reopen the issue.

Closed (fixed) - this status is used exclusively by the Project issue tracking system to close "Fixed" automatically after two weeks of inactivity.

Priority levels

Task priority should indicate it significance. More significant tasks is considered first.

Critical - critical bugs either render a system unusable (not being able to create content or upgrade between versions, and the like), or expose security vulnerabilities. These bugs are to be fixed immediately.

Major - issues which have significant repercussions but do not render the whole system unusable are marked major. An example would be a PHP error which is only triggered under rare circumstances or which affects only a small percentage of all users.

Normal - this is the default priority levels of a new issue. Bugs that affect one piece of functionality are normal priority. An example would be the category filter not working on the database log screen. This is a self-contained bug and does not impact the overall functionality of the software.

Minor - minor priority is most often used for cosmetic issues that don't inhibit the functionality or main purpose of the project, such as correction of typos in code comments or whitespace issues.


A broad grouping of the kind of issue.

Bug report  is used for errors.

Feature request   is used when asking for new features that will enhance a project.

Support request is used when you need assistance using the project (general question, missed in documentation).

Task  is used for things that should get done, but do not fit into another category, such as deleting comments from a page. 



Definition: which area of the project the issue effects. This will vary by project, as each project may choose their own list of components to present. Component of NetK: 

Content moderation  - different content operations: adding, moving, deleting of nodes, areas, etc.

Documentation  - project documentation.

Image generation  -  scheme presentation in .gif file suitable for printing, etc.

Install process - initial setup and configuration

Other - issues which can't be covered by any other components .

Permissions  - user's roles and access levels.

Reports  - reports generation for numeric scheme representation and accounting.

Scheme visualization  - node linking, showing and hiding, node's fields output, etc.

Search engine - search for nodes and network clients.

User interface - whole project user interface message.


 Main    Download    Documentation    Demo    Bug tracking    License    Blogs