Help documentation is outdated

[larspalo]

A few of changes that were made has outdated the help documentation. In order to do an official release the help section should be updated to reflect the current state.

[oleg68]

@larspalo May we do it later?

[rousseldenis]

@larspalo May we do it later?

Later is usually... never.

Keeping good practices would help keeping high level of quality we offer to users (If we want it obviously). Moreover if we want sample editors to keep or to re-adopt GrandOrgue format.

From my point of view, that can help us to formalize also what has been achieved (and not). But I let @larspalo decide as he has more vision of what has been done before and what level he wants.

[larspalo]

Actually, for me, it's a release stopper. A help that's not up to date with the app is worthless. A good practice would be to never make any changes to the GUI or change/add features that's not also at the same time documented in the help. I've started updating the help and can do it for the first release but at the moment no changes should be done up to the release other than such not visible in the app itself. We have lots of things to do anyway just to get up to speed...

[larspalo]

Anyway, another question to you as I'm not really used to either git or GitHub... A possible workflow as I understand it is to have a fork of the official repository of my own that has a master branch that's always in sync with the official master, then every issue I'm working on should have a branch of its own that I can create a pull request from to the official repo, right? Then I can easily isolate my changes and not mix things up, right? Or are there any other, better approaches?

[rousseldenis]

Anyway, another question to you as I'm not really used to either git or GitHub... A possible workflow as I understand it is to have a fork of the official repository of my own that has a master branch that's always in sync with the official master, then every issue I'm working on should have a branch of its own that I can create a pull request from to the official repo, right? Then I can easily isolate my changes and not mix things up, right? Or are there any other, better approaches?

In fact, usually, people have no access to target repository, so they fork the original repository, create a branch based on the target repository/branch, push it to their repository (as they have access to it).

If they consider, their fix/improvement is worth value, they make a pull request to the original repository.

In our case (Oleg, you and me), we have write access to repository, so, we can create branches here. But, it make the list of available branches grow (until deletion). Some may be disturbed, some not.

[oleg68]

@rousseldenis could you approve two PRs for closing this issue?