We aren't following this rule in the `docs/es/features/graphql.md` file
because we need to specify the HTML ID attribute of an element (since by
default markdown generates IDs based on the text, and the text contains
accented letters).
Ideally we would simply ignore this rule on this file, but it isn't
currently possible with Markdownlint, so, until we find a better
solution, we're removing this rule.
We've considered keeping the rule and using heading IDs like:
```
## Características {#caracteristicas}
```
However, this syntax isn't supported by every application rendering
markdown. For instance, github doesn't support it, and we're aiming to
have a documentation that can be read on either github or gitbook.
We were following it about half of the time and we even added it to our
former `.mdlrc` file. However, for some reason, MDL doesn't detect this
rule when specified in the `.mdlrc` file, so we didn't notice we weren't
following it in many cases.
Now that we're using a style file to configure MDL, we can enable this
rule again and apply it, since now MDL correctly includes it in its
report.
Not sure whether it's a good idea to end a heading with a question mark.
When in doubt, we usually keep the code as it is now, so that's what
we're doing.
This way we'll be able to customize some of the rules, which doesn't
seem to be possible when using the `.mdlrc` file.
For simplification purposes, instead of including all rules one by one,
we're excluding the few rules we don't use.
Since the page contains an <h1> tag (the title of the issue), the main
headings of this file should be level 2 headings.
We're removing the "How" section in the flaky specs template for
simplicity (and because we usually don't use this template at all).
Note that MDL reports that the first heading should be a level 1
heading, but, as mentioned earlier, this doesn't make sense in the
context of a github issue. We'll probably exclude these files from MDL
checks in order to avoid this issue.
These files are essentially the same as our README files, only our
README files contain information that only makes sense in the context
of a repository.
On GitBook, currently Spanish and English belong in different spaces, so
we're going to provide two different github integrations (one per
language).
So we're using a different SUMMARY.md file per language.
For consistency, since there was a link to the README file in the
Spanish summary, we're also adding it to the English one. It was working
in any case because on our current gitbook page the summary was
generated through gitbook.
Since we no longer have any of the files referenced in the
`.gitbook.yaml` file, we're removing it as well.
Note that there was a typo in the English summary, which pointed to the
Spanish license. It didn't matter, though, since the license file is
actually in English in both cases.
These files were both in the Consul Democracy repository and the
documentation repository. Since now both repositories have been merged
into one, we can remove the duplicate files.
Note there was a small difference in the `.mdlrc` file because we
changed it in commit b3a718ae6. We're keeping this change so we don't
get these syntax warnings in the documentation.
The main reason for this change is that Pronto doesn't run in pull
requests opened by external contributors, and we haven't found how to
fix this issue.
Another reason is that Pronto only detects issues in the lines where the
changes are done, but sometimes we introduce issues related to other
lines and those aren't detected by Pronto. Also, when adding or changing
Rubocop rules, or when we update Rubocop, Pronto doesn't check whether
those rules are applied in every Ruby and ERB file, and we sometimes
forget to do so (particularly in ERB files).
So, from now, the linters will check all the code in every pull request.
Note we're now excluding the `vendor` folder in our linters because the
`setup-ruby` action actions generates a `vendor/bundle/` folder with all
our gem dependencies, and we don't want to check those files.
We had the `*` because, in the past, pull request could be opened by
either dependabot or dependabot-bot. That's no longer the case since we
started using dependabot v2.
We can't simply remove the nesting selector in this case since it's
inside a `:not` pseudo-class. Removing the nesting selector would cause
a syntax error.
This file was generated by a different developer who ignored the nesting
rules. Refactoring it has been in our TODO list for years, but we
haven't done it yet.
Since we want stylelint to check that there are no errors after the
changes in a pull request, but we've still got errors in this file,
we're ignoring them for now.
Since now we aren't just using ESLint in the context of a pull request
(with pronto-eslint), we're also adding the `ignorePatterns` option so
it ignores third-party files.
Note we're using ESLint 8 because ESLint 9 doesn't support our
`.eslintrc` configuration file, which we need because it's required by
pronto-eslint. However, when running pronto-eslint, we're using ESLint 6
(I think); this means that now the eslint command we run in development
and the one run by pronto might behave differently, particularly if we
add rules that have been introduced in ESLint 7 or 8. For now, since we
generated the `.eslintrc` file using ESLint 6.0.1, everything works as
expected in both situations.
We're excluding these files because they use `raw` to render content
than only administrators can edit, and we trust administrators not to
provide unsafe HTML. We should definitely sanitize them at some point
but, at the same time, we should also try to keep compatibility in
installations taking advantage of `raw`.
Also note that ERB Lint does not allow customizing the severity of a
linter; if it ever does, we'll use the severity rule instead of
excluding files.
In commit 9329e4b6e, `try` was added because there was a case where this
partial was rendered and the `current_booth` method didn't exist.
However, that's no longer the case since commit d5c7858f6. Since then,
this partial is only rendered in the officing section, where the
`current_booth` method is defined.
So we can use the safe navigation operator instead of `try`.
In commit 35659d441, we started using an <svg> tag instead of an <img>
tag to render avatars. That meant that the `vertical-align: middle` rule
we've got for images was no longer being applied.
So we're adding it back.
The only places where this icon wasn't rendered correctly were "my
account" and the show action in the users controller. The comments were
not affected because we've got a `float: left` rule for the
`comment-avatar svg` selector, which causes the browser to ignore the
value of the `vertical-align` propertly, and the avatars showing author
information were not affected because the `.author-photo` selector
already had a `vertical-align` rule.
We were doing it most of the time, but in some cases we were clicking
the "Sign out" link instead. These actions aren't the same, just like
using `login_as` is not the same as visiting the sign in page and
submitting the form.
Some of these tests failed sometimes because the user wasn't signed in
after using `login_as`. One possible cause could be that we weren't
adding an expectation after clicking the "Sign out" link.
So using `logout` adds consistency, simplifies the code, and might
reduce the chance of these tests failing in the future (although they
might still fail in the future because some of these tests check the
database after a `visit` call).
In this test, we were signing out after confirming a vote, but we
weren't waiting for the request to finish before using the `login_as`
method. Sometimes this test failed with a screenshot showing that the
user wasn't signed in after the `login_as` call, so this might have been
the cause.
We could use the `logout` method instead, but since we don't have any
other tests that click the "Sign out" link from the officing area, we're
leaving it as it was; we might change it to `logout` in the future if
the test keeps failing once in a while.
Note we're also replacing a `visit` call which my guess is was there
because the "Sign out" link wasn't visible due to the notice covering
it. So we're closing the notice instead.
