Document onboarding and internal day-to-day processes

[juliamagan]

Description

Currently, there is an internal documentation where we can find onboarding and internal day-to-day processes. However, this documentation is probably outdated. It is necessary to review this documentation and change it according to the latest adopted processes.

Objectives

• Review current documentation
• Delete outdated documentation
• Add new documentation:
  • Feedback
  • Work thread
  • Status
• Publish documentation

[juliamagan]

Update 19/06/2023

The documentation has been revised and a document has been created where the documentation that will go to the general level of the development team has been eliminated and the outdated one has been improved.

In addition, documentation of processes that still need to be defined will be marked as To-do.

It remains to publish this new documentation.

[juliamagan]

Update 20/06/2023

Documentation published and reviewed by the team. Once reviewed by @davidjiglesias, this issue will be On hold until we can update the sections marked as To do.

[juliamagan]

Update

Requested changes: document team channels

[juliamagan]

Update

Documented team channels

[damarisg]

The title is confusing, and the content of the description. Does it only add the internal communication section?

Review about that:

Case 1: Page

• The information is correct. However, the visibility of titles and sections needs to be improved, also the indentation of texts. Now, It's confusing because everything looks stacked and cannot be distinguished.
• Is the QA-management sheet section still used?

[damarisg]

I add the review of the rest of the Onboarding selection (an extra). I add the information so there is evidence of what has been worked on, and it is taken into account when working on it.

Extra Review

Case 1: Page

1. Fix Title: It is Onboarding not On Boarding.
2. Is it required to add a Note section? I recommend removing this.
3. Suggestion to change Summary titles:
   • Setting up
     • Recommended working tools
   • The QA team
     • Internal communication
     • Methodology
     • Repositories
   • About us
   • Getting started change to: Start with tasks or Introductory tasks
     • Wazuh
     • QA

---

Case 2: Page

1. Fix Title: If you will keep the the title you need change Recomended to Recommended.

2. Clockzy section would improve it to:

   Clockzy is a Slack app for managing the workday and displaying useful reports. This application has the following objectives:
   - Record entry, pause, back, and exit actions during the workday.
   - Calculate the hours worked and display the results quickly and conveniently.
   Note:
   - In case of linking with Intratime, perform actions directly from a slack command, without having to access Intratime.
   - To start using it, simply type /sign up to any Slack channel within the Wazuh-team.slack.com workspace.
   - You can type the command /help to see the available actions.
   - You can find more information in the readme of the repository.

   I would not say that Mauro maintains it because all QA is supposed to know about it. And putting specific person names for everything makes it hard to maintain sites or docs. Please, add the correct identation.

3. Visual Studio Code section. There is a bit of redundant information, in order to reduce and be specific, I eliminated some lines, leaving it like this:

   Visual Studio Code is a source-code editor made by Microsoft for Windows, Linux, and macOS. Features include support for debugging, syntax highlighting, intelligent code completion, snippets, code refactoring, and embedded Git.

   As main plugins to install, we recommend the following:

   • Python
   • Git History
   • GitLens
   • Remote SSH
     Note: Although VS Code is linked to Github, do not use it to do git related things, like push commits, push branches, etc., as it may not work as expected. It is always better to do it from the terminal.

4. Virtualbox section should be remove:
   - Line: This software is used in conjunction with Vagrant for rapid deployment of virtual instances based on base images.
   - Line: For more information, see its download page. If you add download page for it, you need to add the download page for each tool recommended.

5. Vagrant section should remove the:

   • Paragraph: To summarize, it is enough to define in a file called Vagrantfile what infrastructure and how it is going to be deployed, using base images called boxes, which are downloaded automatically in case you don't have them in your local repository of pictures. You can create as many images as you want, and by default, you can find many in vagrantcloud.
     If you are not familiar with this tool,

   For that, the name and the page are shared so that the person can read and investigate more in detail.

6. Docker section should remove the:

   • Phrase: If you are not familiar with this tool,

7. Ansible section should remove the:

   • Phrase: If you are not familiar with this tool,

8. Terminator section should:

   • Delete example. If you want to add an example, you must add an example for each section and not just a few.

You always have to be specific and try to put the basic information in each section. For example, there are several tools (Docker, ansible, vagrant, meld, Remmina, Peek) where it is not stated whether or not it is compatible with Windows. If it isn't, there should be a Windows tool added.

Do you consider that the tool Flameshot is necessary to add it? Depending on the OS we work with, we always have a way to do it.

---

Case 3: Page

1. Improve title
2. When listing the different types of problems, change "..." to etc.
3. I would add that the standard for each type of issue is being defined and I would eliminate:

These issues must be correctly written and classified for a good understanding. There is no main figure in charge of creating the issues, but both developers and QA testers can create them according to the requirements and objectives to be met.

It is important to follow the same structure or template to describe each of the issues. By default, when creating a new issue, it is possible to choose a default template to describe a specific type of case.

Here are some examples of issues:
> QA-testing: Manual checks for new developments
> Release testing issues
> New tests development
> Test fixes
>

4. I don't understand the Github issues section, since it's not defined yet. Why is it added?

5. In the Tracking section I would add:

   • Update issue status
   • Make sure the labels, mandatory fields and project.
   • Add a comment WITHOUT DATE in description with our work progress.
   • This section is confusing. There are a lot of information mixed up.
   • Be careful with pages add but not exist. Example: spreadsheet.
   • The documentation, you shouldn't contain the "..."
   • Clarify that when reviewing a PR we need to add the topic in the feedback, not the PR.

---

** Case 4**: Page

1. Improve title

---

[juliamagan]

Update

Applied case 1 from first review, case 1 and part of case 2 from extra review

[juliamagan]

Update

Finish case 2 from extra review

[juliamagan]

Update

Changes applied. Case 3 has not been applied because that page is still in To do, it has been hidden so that there is no possible confusion in the future.

[damarisg]

GJ!
Please, Could you add the proper indent and remove unnecessary spaces in the Internal Communication section? (Image with example)

[juliamagan]

Update

Applied requested changes

[damarisg]

LGTM!

[davidjiglesias]

LGTM!

Initial version approved and published https://sites.google.com/wazuh.com/wazuh-qa-documentation/onboarding