On Wed, Jul 29, 2020 at 10:56 AM Matej Tyc <[email protected]> wrote: > The PR https://github.com/ComplianceAsCode/content/pull/5606 introduced > a large number of changes that may break patches, but those changes were > much needed in the project. So I think that we should use this > opportunity to introduce more changes, so we introduce only one pair of > versions between which things could break, as opposed to breaking many > times in a row in the future. > > So what I think we could consider? > > - Rename description, rationale to html_description, html_rationale. > Reason: We could start to introduce Markdown input, and doing it this > way would allow us to do it gradually. We probably want to have html as > a canonical form, but we could offer more possibilities for content > authors. >
I don't think changing keys like this makes sense or adds value, and in fact, will make things more confusing. Just supporting markdown in the text would better and easier for people to understand. > > - Restructure project's folder structure - right now, the list of > products is really long, which makes the project page too long. Having > products in a separate directory would also allow us to get a list of > supported products programmatically from the filesystem. > I really don't want to do this again. Not in favor, and there is nothing preventing getting the list programmatically right now. > > - Put macros where they belong. We have plenty of boilerplate in the > project, and macros can keep the code readable and free of duplicates. > Moreover, if people use a macro to e.g. instantiate an XCCDF variable, > we can change the underlying implementation without breaking the public > API. > > Most of these changes is just about crafting and running a sed command, > plus comparing the result before and after - I have in mind large-scale > changes that don't require a large amount of time to perform. > > What do you think? Do you have other suggestions you would add to the list? > - Merging platform and prodtype together - getting rid of jinja in rules and using the industry standard of tailoring to increase readability - Divorce the content from the build system like Chef Inspec, Ansible, and other security tooling that is coming from the government. - Feedback from many consultants and SAs is that things need to be made easier and simpler. That it's too hard to do anything. - Moving all product configurations necessary to add a new product from code to product.yml > _______________________________________________ > scap-security-guide mailing list -- > [email protected] > To unsubscribe send an email to > [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] >
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
