Wiki info¶

The NLSR Redmine tracker is where NLSR-related work is coordinated. This includes work items, such as bugs, tasks, and feature requests, as well as design discussion.

In the future (from May 2017), the wiki should also be a location to deposit accumulated knowledge about NLSR, including design documentation, usage documentation, and troubleshooting/FAQ.

Issue categories¶

The tracker has three issue categories: bug, task, and feature.

• Bug should be used to describe, well, bugs. This includes any situation where NLSR is not behaving as expected. This tracker should not be used for things like changing deprecated APIs, problems compiling NLSR, or discussion about experiments. This tracker should be strictly limited to material deficiencies in NLSR code that result in undesirable behavior. A good bug issue will have:

  • A detailed description of the bug as it occurred.
  • A description of the hardware that the bug occurred on
  • Any relevant log files (be sure you turned on logging)

• Task is the main category, and should be used fo any work item. Further, these items should be "actionable," in the sense that they represent tasks, not goals. Goals go in the feature tracker. Anyone that reads a task issue heading should, in theory, be able to sit down and begin work almost immediately.

  • Good examples of task headers are "design X component", "refactor class Y", or "implement function Z"
  • Bad examples of task headers are "enable X", "implement feature Y", or "finish Z". What do you have to do to enable X? What in the code needs to change to implement that feature? What does finishing something even mean?

• Feature should be used to group tasks together into "milestones" or "goals" or "user stories", whatever lingo suits you. The intent of the features tracker is to describe what NLSR can do, and aggregate tasks that move the state of NLSR closer to that endpoint. These may be things like improving documentation, supporting a new library function, or targeting a new platform. Generally, features should describe states, not actions. Actions go in the task tracker. If a feature represents a state, then its tasks should represent a set of actions that can move NLSR to that state. Naturally, they do not have to be exhaustive when the feature issue is created.