Yes, if what you’re talking about will produce some code.
By the way, it’s perfectly reasonable not to fill issues for
occasional small fixes, like typos in translations.

Issues are not a TODO list. Issues track the status changes of a job, the
output of the job will be a new RPM resolving the issue itself.
If you are exploring some esoteric paths for new feature or hunting
something like a heisenbug
, please write a draft wiki page with your thoughts, then create a new
issue only when you’re ready to write a formal description and produce
some output object.

Feature planning is kept inside https://github.com/orgs/NethServer/projects/.
For any new feature, create a new card under the Future column.
The card should contain a brief description of the feature, the link to the discussion
and eventually links to related wiki page and issue.

At any point in time, make sure the card and the issue reflect the status of actual work.

Takes an unassigned issue with label testing and sets the Assignee field
to him/herself.

Tests the package, following the test case documentation written by the
Developer.

When test finishes he/she removes the testing label and clears the Assignee
field. If the test is successful, he/she sets the verified label,
otherwise he/she alerts the Developer and the Packager to plan a new
process iteration.

When merging a PR, make sure to copy the issue reference inside the merge commit comment body, this step will be used by automation tools:

to write notification about published RPMs inside the referenced issue

to automatically create RPMs changelog

If the commit history is not clear enough, or you want to easily revert the whole work, it’s acceptable
to squash before merge. Please make sure the issue reference is present inside the comment of the squashed commit.

Before creating a new package, make sure it’s a good idea. Often a simple
documentation page is enough, and it requires much less effort. When trying new
things, just take care to write down on a public temporary document (maybe a
wiki page) all steps and comments. If the feature collects many requests, it’s
time to think about a new package. Otherwise, the temporary document can be
moved to a manual page.

When creating a new package, make sure the following requirements are met:

Before any final ISO release, the software development process goes through
some test versions, usually called alpha, beta and release candidate (RC). These
releases are an excellent way to experiment with new features, but may require
some experience using a Linux system and/or the command line.

Alpha releases are not ready to be used in production because some features
are not finished, furthermore upgrade to the final release will not be supported
(but may be possible).

Beta releases could be used in production, especially if new features are
not used on mission-critical systems. Upgrades to the final release are
supported.

Release candidates (RC) can be run in production, all features are supposed
to be complete and bug-free. The upgrade to the final release will be minor
or less.