Add CONTRIBUTING.md

[savq]

No description provided.

[piechologist]

@Pangoraw: I think adding these contributing guidelines is a good idea. I'm also wondering if we should enable the Wiki to gather some config options etc. What do you think?

[savq]

enable the Wiki to gather some config options etc.

Do you have something specific in mind? Github wikis don't have a lot of visibility, so if we do add one, it should be mentioned prominently in the README

[piechologist]

Do you have something specific in mind?

1. I would document the captures that are not defined in Zed's default color themes.

2. I think we need some documentation for the LS and Zed's REPL mode. I don't use either but I feel bad when looking at the open issues.

For instance, the wiki here helped me a lot to get running. There's a FAQ and Troubleshooting section in the README that points to their wiki.

Discussions could be another option.

[steffenhaug]

Documenting the captures that are not defined in Zed's themes is a good idea. I don't know how many of these there are? I agree that Wikis have poor visibility; maybe a list in the README is okay if there are not that many? Or maybe an example theme override config that covers all the ones missing in default themes?

In my experience, Wikis work well when there is a large amount of information that is not relevant to everyone, for example the Neovim Wiki pages with instructions for setting up LSP for a myriad of different programming languages. However, for things that "most people" are likely to encounter, it makes sense to put it in the README, because that's where most people go first when troubleshooting.

[piechologist]

We're currently using:

@boolean
@comment
@comment.doc
@constant.builtin       // no default, falls back to @constant
@function.builtin       // no default, falls back to @function
@function.call          // no default, falls back to @function
@function.definition    // no default, falls back to @function
@function.macro         // no default, falls back to @function
@keyword
@keyword.conditional    // no default, falls back to @keyword
@keyword.conditional.ternary  // no default, falls back to @keyword
@keyword.exception      // no default, falls back to @keyword
@keyword.function       // no default, falls back to @keyword
@keyword.import         // no default, falls back to @keyword
@keyword.operator       // no default, falls back to @keyword
@keyword.repeat         // no default, falls back to @keyword
@keyword.return         // no default, falls back to @keyword
@number
@number.float           // no default, falls back to @number
@operator
@punctuation.bracket
@punctuation.delimiter
@punctuation.special
@string
@string.escape
@string.special
@string.special.symbol
@type
@type.builtin           // no default, falls back to @type
@type.definition        // no default, falls back to @type
@variable
@variable.builtin       // no default, falls back to @variable
@variable.member        // no default, falls back to @variable
@variable.parameter     // no default, falls back to @variable

Zed's default themes are here. They contain some more tokens we don't use.

I can write a short introduction with the table above and append it to the README or put it somewhere else?

[steffenhaug]

Hmm, that is quite a few. Maybe a Wiki page and a prominent mention in the README is appropriate in this case.

It can always be moved if it becomes clear that people aren't finding it.

[Pangoraw]

@Pangoraw: I think adding these contributing guidelines is a good idea. I'm also wondering if we should enable the Wiki to gather some config options etc. What do you think?

I agree that this is a good idea, thanks @savq !

We can also enable the wiki if there is a need for it, though I would personally prefer having the docs in the repo so that it is easier to keep in sync when making changes.

[piechologist]

I would personally prefer having the docs in the repo

Good, I suggest we merge this PR, then I'll make a separate one to extend the README.