Skip to content

WebTop development process

Jump to bottom
Giacomo Sanchietti edited this page Sep 10, 2019 · 16 revisions

This document is just a draft, a full review is required - Source: https://docs.google.com/document/d/1V8NY_qpOpyJCsT-1Nzae5TvstgArhzIs0v081iP6Ejs/edit

Introduction

This document describe the development process between Nethesis and Sonicle. Nethesis integrates WebTop, developed by Sonicle, inside NethServer.

Roles

  • Project Manager (PM): Luca Gasparini
  • Development Team: ...

New feature requests (NFR)

NFR can be requested from a NethServer community member, from a Nethesis partner or from the PM himself.

NFR from Nethesis partner: if the request is not really interesting (how is this decision taken?) the partner is requested to open a discussion inside Nethesis partner forum. The features will be evaluated on the generated interest.(How this NFR is collected in the first place? From a helpdesk ticket?)

Interesting FR (what does it mean 'interesting' here?): a new card is created inside the project board under the column "FR DA VALUTARE CON SONICLE".

The PM schedules a periodic meeting with the development team (which team? who is part of the team?).

  • Accepted NFR: the card is moved under "ACCETTATE (da pianificare)" column, waiting for a schedule
  • Rejected NFR: the card is moved under the the "-- REJECT --" column

Under the "IN ORDINE DI PRIORITA’" column, the cards are picked (or copied?) from "CARD ROADMAP" and "ACCETTATE (da pianificare)".

The PM, with the development team (again, which team?), decide the STEP (what is a step?) composition. The STEPs must be composed picking cards from the "IN ORDINE DI PRIORITA'" column.

When a NFR is planned inside a STEP, the developers (who are the developers?) will open an issue. The link of the issue must be reported inside the card by Luca (*why this shouldn't be done by the developer?)

Bugs

(How a bug can be reported? Who is in charge of opening the issue?)

A bug should be filled inside Sonicle issue tracker. The following fields must be filled:

  • Affects Version
  • Steps to reproduce
  • Expected behavior
  • Actual behavior

If available, attach to the issue screenshots and logs which can help to describe or reproduce the issue.

Quality Assurance (QA)

When a new testing release is ready (what is a testing release? is it the output of a STEP?) a new staging WAR is published inside the staging area.

To obtain the list of modifications included in the last staging WAR see this query.

Sonicle announces the staging release by sending an email to the PM (why not create a public ML or something similar?). (Suggestion: the PM announces the staging release inside the team chat creating a new thread with the WAR number. All problems will be reported under such thread)

Staging releases can be tested on a running NethServer using this script.

At the end of the QA (who is in charge of the QA?), the PM report by mail the test results to Sonicle (how can we make this info public?). (Suggestion: move the communication to the team chat or directly to the issue tracker).

If all tests are green, the development team (should be Sonicle?) executes the following steps:

  • it pushes everything to GitHub creating a new git tag like wt-5.x.x. (Why everything is not already available? what is the source to be checked? Should we use Jira to pull the sources?)
  • the new tag is added inside all issues in the "Release Version" field
  • release notes are published inside the official doc
  • the release is be announced to the PM using mail (can we switch to a public address, ML or something else?)

If tests fail, new issues will be created or old ones will be reopen (why issues are not closed after the QA?).

Tools

Clone this wiki locally