This chapter contains a lot of information about the development process the
Nextcloud community tries to follow, so please take your time to digest all the
information. In any case remember this page as the documentation on how it
should be done. Nothing here is set in stone, so if you think something should
be changed please discuss it on the forums.

To keep us focused on finishing issues that we started, new issues will be
hidden in this column. In HuBoard you can see the list of things that we could
think about by clicking the small arrow in the top left corner of the concept
column header.

What does a developer think?

“Maybe later.”

When can I pull?

Since this is the bucket for whatever might be done you should only pick
issues from the backlog when there is no other issue that you can work on. It
is more important to finish an issue currently on the Kanban board than to
pull a new one into the flow because only released issues have a value to our
users!

Who is Assigned?

Either a maintainer feels directly responsible for the issue and assigns
himself or the gatekeeper (the guys having a look at unassigned bugs) will try
to determine the responsible developer.

Our think before you act phase serves two purposes. A Bug is in the concept
phase while we are trying to figure out why something is broken (analysis). An
Enhancement is in the concept phase until we have decided how to implement it
(design).

As long as you think and discuss on how to implement an enhancement or how to
solve a bug you should leave the concept label assigned. Two things should be
documented in a comment to the issue before moving it to the “To develop”
step:

At least one Scenario – written in Gherkin – that tells you and the tester
when the issue is ready to be released.

A concept describing the planned implementation. This can be as simple as
a “this just needs changes to the login screen CSS” or so complex that you
link to a blog entry somewhere else.

Now that we have a plan, any developer can pick an issue from this column and
start implementing it. If the issue is also marked with Junior Job this might
be a good starting point for new developers.

What does a developer think?

“Nice! I can safely implement it that way because more than one person has put
his brain to the task of coming up with a good solution. Here! Me! I’ll do
it!”

When can I pull?

If you feel like diving into the code and getting your hands dirty you should
look for issues with this label. In the comments, there should be a Gherkin
scenario to tell you when you are done and a concept describing how to
implement it. Before you start move the issue to the “Developing” step by
assigning the “4 – Developing” label.

This is where the magic happens. If it’s a Bug the fix will be submitted as a
PULL REQUEST to the master or corresponding stable branch. If its an
Enhancement code will be committed to a feature branch.

What does a developer think?

“You know, I’m at it. By the way, I’ll also write unit tests. When I’m done
I’ll push the issue with a commit containing “push GH-#” where # is the issue
number. If I have an idea of who should review it I can also notify them with
@githubusername”

When can I pull?

As long as you are writing code for the issue or if any unit test fails you
should leave the “4 – Developing” label assigned. Two things should have been
implemented before moving the issue to the “To review” step:

Instead of directly committing to master we agree that a second set of eyes
will spot bugs and increase our code quality and give us an opportunity to
learn from each other. See also our documentation about Code reviews on GitHub

What does a developer think?

“I’ll check the Scenario described earlier works as expected. If necessary
I’ll update the related Gherkin Scenarios. Drone will test the scenario
on all kinds of platforms, Web server and database combinations with
Cucumber.”

When can I pull?

If you feel like making sure an issue works as expected you should look for
issues with this label. In the comments you should find a Gherkin scenario that
can be used as a checklist for what to try. Before you start move the issue to
the “Reviewing” step by assigning the “6 – Reviewing” label.

With the Gherkin Scenario from the Concept Phase reviewers have a checklist to
test if a Bug has been solved and if an Enhancement works as expected. The
most eager reviewer we have is Drone. When it comes to testing he soldiers
on going through the different combinations of platform, Web server and
database.

What does a developer think?

“Damn! If I had written the Gherkin Scenarios and Cucumber Step Definitions I
could leave the task of testing this on the different combinations of platform,
Web server and database to Drone. I’ll miss something when doing this
manually.*

When can I pull?

As long as you are reviewing the issue you should leave the “6 –
Reviewing” label assigned. Before moving the issue to the “To review” step the
issue should have been resolved, meaning that not only the issue has been
implemented but also no other functionality has been broken.

This is a list of issues that will make it into the next release. It serves
as a source for the changelog, as well as a reminder of the work we can already
be proud of.

What does a developer think?

“Look at all the shiny things we will release with the next version of
Nextcloud!”

When can I pull?

This is the last step of the Kanban board. When the Release finally happens
the issue will be closed and removed from the board.

Who is Assigned?

No one.

While we stated before that we push issues to the next column, we can
of course move the item back and forth arbitrarily. Basically you can drag the
issue around in the HuBoard or just change the label when viewing the issue in
the GitHub.

How can you possibly review an issue when it requires you to test various
combinations of browsers, platforms, databases and maybe even app combinations?
Well, you can’t. But you can write a Gherkin scenario that can be used to write
an automated test that is executed by Drone on every commit to the main
repositories. If for some reason Drone cannot be used for the review you will
find yourself in the very uncomfortable situation where you release half tested
code that will hopefully not eat user data. Seriously! Write Gherkin scenarios!

Panic should be used with caution. It is reserved for Bugs that would result
in the loss of files or other user data. An Enhancement marked as Panic is
expected by Nextcloud users for the next release. In either case an open Panic
issue will prevent a release.

Attention is not as hard as Panic. But we really want this in the next release
and will dedicate more effort for it. But if we think the issue is not ready
for the next release we will postpone it to the next one.

Regression is something that worked in a previous release but is now not
working as expected or missing. If a certain functionality is up for code
refactoring, the developer should describe all possible use cases as a Gherkin
scenarios beforehand, so that any scenarios that isn’t implemented before the
required milestone can be marked as a regression. If a regression is found
after a release, the reporter – or the developer triaging the issue – should
describe the functionality as a Gherkin scenario and either fix it or assign
it to the developer in charge of that part.

Releases are planned via milestones which contain all the Enhancements and Bugs
that we plan to release when the Deadline is met. When the Deadline approaches
we will push new Enhancement request and less important bugs to the next
milestone. This way a milestone will upon release contain all the issues that
make up the changelog for the release. Furthermore, HuBoard allows us to filter
the Kanban board by Milestone, making it especially easy to focus on the current
Release.