[Proposal] New/Updated Schema for Question Catalogue (versions, id etc.)

[timonf]

The current schema:

• does not have identifiers (it's hard to synchronize questions with a database!)
• does not support versioning (mentioned in certificationy/symfony-pack#51)
• supports a help column in questions, but is never used in certificationy/symfony-pack or certificationy/php-pack
• supports only yml (without a) file extension (not used by Symfony 4 anymore)

So I want introduce my proposal for an updated schema:

• id (just random generated uuid), so we can identify updated questions easily
• version should work similar to composer requirements (symfony: "^2.3" for Symfony 2.3 to 2.8)
• question field should contain text or inline YAML (so we can highlight code blocks easier, if we want to show questions in a browser); YAML is also easy readable for humans :)
• we should use the help field! (would be also easier to review contributions, as I discovered the process thing from the symfony3.yml works also in Symfony 2.3!)
• we should rename files to .yaml to have a familiar feeling with Symfony 4

This is what an updated YAML file could look like:

# components.yaml (instead of symfony3.yml in certificationy/symfony-pack)
category: Various Symfony Components
questions:
    -
        id: 'ded068d9-e76e-415a-995c-2a26e9c73f9f'
        question: 'What is the default signal sent by Process component to stop a process?'
        versions:
            symfony/symfony: '^2.3|~3.0|~4.0'
        help: |
            https://en.wikipedia.org/wiki/Signal_(IPC)
            https://symfony.com/doc/2.3/components/process.html#stopping-a-process
            https://github.com/symfony/process/blob/2.3/Process.php#L636
            http://php.net/manual/en/pcntl.constants.php
        answers:
            - {value: 'SIGINT',        correct: false}
            - {value: 'SIGKILL',       correct: true}
            - {value: 'Process::STOP', correct: false}
            - {value: '9',             correct: true}
    -
        id: 'ebc9ed55-dcb0-46eb-9003-d135b57b4e95'
        question: |
            What can be placed in `?????` to be valid?

                use Symfony\Component\Yaml\Yaml;

                $value = Yaml::parse(?????);
        versions:
            symfony/symfony: '^2.2'
        help: |
            https://symfony.com/doc/2.3/components/yaml/introduction.html#reading-yaml-files
            https://github.com/symfony/yaml/blob/2.3/Yaml.php#L44
        answers:
            - {value: '"/path/to/file.yml"',                    correct: false}
            - {value: 'file_get_contents("/path/to/file.yml")', correct: false}
            - {value: 'Both are valid',                         correct: true}
    -
        id: '7e89f317-dd3c-487b-9bd2-ff700e1d0d4a'
        question: |
            What can be placed in `?????` to be valid?

                use Symfony\Component\Yaml\Yaml;

                $value = Yaml::parse(?????);
        versions:
            symfony/symfony: '~3.0|~4.0'
        help: |
            https://symfony.com/doc/3.0/components/yaml.html#reading-yaml-files
            https://github.com/symfony/yaml/blob/3.0/Yaml.php#L41
            https://github.com/symfony/yaml/blob/3.0/Parser.php#L60
        answers:
            - {value: '"/path/to/file.yml"',                    correct: false}
            - {value: 'file_get_contents("/path/to/file.yml")', correct: true}
            - {value: 'Both are valid',                         correct: false}

Example (default) configuration for CLI:

paths:
    - "vendor/certificationy/symfony-pack/data"
    - "vendor/certificationy/php-pack/data"
versions:
    http: '1.1'
    php: '^5.3|~7.0'
    symfony/symfony: '^2.3|~3.0|~4.0'
    twig/twig: '1.*|~2.0'
    doctrine/orm: '^2.2'

Pros:

• A lots of easier to test twig, http or php only (using "versions")
• Personal progress can be saved easier using the IDs

Things to discuss:

• yey or ney?
• versions? → composer package names (or just some aliases like php, symfony, twig, doctrine etc.)
• how can versions be filtered later (arguments in cli, or configuration)?
• update this library to support versions and ids? (maybe generate a random fallback id, if id is not provided by given YAML file)

[timonf]

After some research I found versions already. But where they are gone?

[timonf]

What do you think, @mickaelandrieu? I already committed a prototype of version support :)

[mickaelandrieu]

yey or ney?

yey and ney :)

versions?

I'm still against version/versions: this will conflict with git versionning for no gain. This make the cli app harder to use and understand. Regarding the symfony package, I don't think it was worth, same apply for PHP and we don't really have new packages right now.

For ids, I do agree "but" I don't want people to be forced to add it: it should be up to the library to require a new dependency like ramsey/uuid and fill the ids. Who will really take time to generate an uuid to add new questions? We don't have a lot of contributors right now and I don't want to make the contribution workflow harder. My main concern is always: "how can we have more contributors to the decks?"

support of yaml instead of yml

Why not, the app should still depends on Symfony 3 LTS until the release of Symfony 4.4

[timonf]

Thanks for your answer, @mickaelandrieu!

I'm still for versions! Currently you are able to take the exam for Symfony 2.3, 3.0 or 4.0! And you have different requirements for each version. See exam topics. One example: The ExpressionLanguage component is introduced in Symfony 2.4. So it's not part of the Symfony 2.3 certification. But it will maybe part of the Symfony 3.0 and 4.0 certification.

For my proposal and implementation: I don't expect much trouble in CLI, because the example configuration (in CLI) could allow multiple versions by default (symfony/symfony: "^2.3|~3.0|~4.0", php: "^5.3|~7.0" etc.). Moreover version attributes would be optional. When no version is provided by question or config/cli: Given question will be added to the current set. You can have a look at the unit test data here. The first question will be available in both sets.

The git thing: We could also create 3 branches/versions for the certificationy/symfony-pack (2.3, 3.0 and 4.0). But this would have other cons: If someone wants to update many questions for different versions, he maybe have to create multiple MRs/PRs. In addition: certificationy-cli can only have one version dependency via Composer. (Maybe I got your message about git wrong :flushed:)

I definitely want and need version support, to train only for 3.0. If you would accept it, I would also update the symfony-pack. I would add help texts/links and correct version constraints (like in the example above). This would also supports my training :)

Who will really take time to generate an uuid to add new questions? We don't have a lot of contributors right now and I don't want to make the contribution workflow harder.

I would like to contribute more but I also want to add more information to all questions. Yes, it's a little bit harder for new contributions. But quality of existing questions would be increased! As I recommended: versions and id would be still optional. So untouched packs will also work after extending the schema. And new contributors don't have to provide id or versions because they are still optional.

support of yaml instead of yml

I think this is the easiest part. We only have to extend the loader to accept both extensions!