Feature availability matrix

[rosieyohannan]

Note

You may find that there are errors for the vale/lint job that are unrelated to your change.
Vale checks the whole file when a change is made so if there are existing issues on the page they will be flagged.
You can ignore lint errors outside your changes and the CircleCI docs team will address them for you.
Vale logs are advisory to help all contributors create content that conforms to our style guide. The vale/lint job will not prevent changes from being published.

Description

What did you change?

Reasons

Why did you make these changes? What problem does this solve?

Content checks

Please follow our style when contributing to CircleCI docs. View our style guide or check out our CONTRIBUTING.md for more information.

Preview your changes:

• View the Vale linter results, select the ci/circleci: lint job at the bottom of your PR. You will be redirected to the vale/lint job output in CircleCI.
• Preview your changes, select the ci/circleci: build job at the bottom of your PR and you will be redirected to CircleCI. Select the Artifacts tab and select index.html to open a preview version of the docs site built for your latest commit.

Take a moment to check through the following items when submitting your PR (this is just a guide so will not be relevant for all PRs):

Content structure:

• Break up walls of text by adding paragraph breaks.
• Consider if the content could benefit from more structure, such as lists or tables, to make it easier to consume.
• Consider whether the content would benefit from more subsections (h2-h6 headings) to make it easier to consume.
• Include relevant backlinks to other CircleCI docs/pages.

Formatting:

• Keep the title between 20 and 70 characters.
• Check all headings h1-h6 are in sentence case (only first letter is capitalized).

[BeFunes]

• Pull request event triggers
  • Github OAuth --> says YES but should be NO
  • OAuth Server --> says yes but should be no"
• Schedule workflow:
  • I find the description a bit weird, especially since you can find that info follwing the link. Would it be better to say something like "Schedules defined inside the config.yml file"?
• Rerun failed tests:
  • I'm not familiar with support for this feature, but looks suspicious that it's marked NO for Gitlab and YES for Gitlab self managed
• Default checkout method
  • I wonder if the word "default" here is confusing. Would it be clearer to call it "checkout" method? We often say default because nothing stops you from also doing a git checkout ... in your config, but...
  • I'm really not sure about what category we should slot this in!
• Do we need a "requires deploy key for checkout" in the same category as "Default checkout method"? 
• "Reduced permissions when integrating with CircleCI. Select a subset of repositories to be used with CircleCI."
  • this sounds like a negative because of the word "Reduced". Maybe fine-grained permissions? Selective access to repositories?
  • Would it make sense to jam it in the "security" category?
• Build from forked repositories:
  • It's marked no for GH OAuth & GH Server, but shouldn't it be yes? And it's marked YES for Gitlab & Gitlab SM, which I'm not entirely sure about. I can verify
• Outbound webhooks:
  • You know how GitHub App, Gitlab, GL SM, BBDC have a different payload as the other integrations... do you think it's worth flagging this, given it makes them quite hard to use?
• CircleCI config suggestions bot
  •  - are we sure this still exists? if this refers to the pipeline-assistant AI-supported experience, should we call it that? (Not sure it's referring to it though!! Laureen should know more about this point)