repository management: determine prefixes for issues and changelists

[stamblerre]

The typical practice in the rest of the Go project is to prefix issues and CLs with the name of the package they pertain to. This doesn't really make sense for this repository, as there are no Go packages.

These issue prefixes are helpful for classification, so it'd be nice to stick with them, but we don't seem to have a consistent strategy for applying them. doc is useful for documentation changes, but the analogous src for code changes is not really useful. We should restructure the code in such a way that we can have useful prefixes.

Furthermore, for issues, I think we need to create prefixes, some of which may collide with existing labels. For example, debug is useful as a prefix for skimming issues quickly, but also useful as a label for quick searches.

/cc @hyangah

[hyangah]

For changes to files in src, using the file level (module) is an option already. (e.g. src/goCover, src/goLanguageServer) Some of the utility modules and small files may be merged or need to be refactored.

Then, all, docs, build, test/gopls, test/integration, syntaxes, snippets, ...

An alternative is the approach like https://www.conventionalcommits.org/en/v1.0.0/ , which allows variations of tools like https://github.com/googleapis/release-please that help automating part of the frequent release process. OTOH, we may use relnote for release note generation instead. In that case, the info can be done through RELNOTE tags in the gerrit cl review comment https://github.com/golang/go/wiki/CodeReview#cl-directives

[stamblerre]

For changes to files in src, using the file level (module) is an option already. (e.g. src/goCover, src/goLanguageServer) Some of the utility modules and small files may be merged or need to be refactored.

Agree with that. Refactoring things so that CLs only affect single modules seems right to me.

Having something to generate release notes would also be awesome - we could use it for gopls too.

[gopherbot]

Change https://golang.org/cl/234240 mentions this issue: another test PR for https://github.com/golang/go/issues/23850

[hyangah]

We need extra rules for issues.

Issues for bugs can use the same rule (culprit module name) if the source of the problem is obvious. Users may not know the actual implementation, so maintainers need to identify them if possible.

But for issues that involve upstreams (go, gopls, vscode, dlv, ...), the choice is not obvious. Maybe just use the upstream name in that case.

New feature requests may not fall into any of the existing modules. For them, 'proposal' or 'feature request'? (I think proposal is a more concrete form of feature request that may include discussion of design and implementation though).

[hyangah]

cc @polinasok @suzmue

[polinasok]

Would it perhaps make sense to go over the last X PRs and/or issues and classify and group them to see what categories are starting to emerge? As for upstream cases, can se use more than one prefix? Like "debug+dlv:..."?

[hyangah]

The current de-facto convention is

• CLs: use the primarily affected directory/file name without .ts as the prefix. The title should follow the Go project's general guideline otherwise. (src/goMain: add a cool feature Foo) For cherry-picked CLs: add the branch name as a prefix (e.g. [release] src/goMain: add a cool feature Foo)

• Issues: no convention. Let's use labels more actively.

We need to document this in https://github.com/golang/vscode-go/blob/master/docs/contributing.md