Standardize issue names

[MetalBlueberry]

Hi all

I've been recently reading through the issues in this repository.

The use of tags is clear enough and I think that is what allows you to manage the high volume of issues. The problem comes when you want to see if an issue already exists before opening it.

If you check the current list, you can notice a title pattern like *topic: description" but is not consistent across issues.

here are some examples

• dvc dag not accepting output files/folders
• [WIP] outs: add desc field
• [WIP] 'dvc vdir' command for updating large remote datasets
• Do we need exec in git hooks?
• experiments: support branching w/modified params from intermediate checkpoint
• Run-cache for experiments and checkpoints
• azure: AzureTree.exists and import-url fix for folders
• dvc: add --pdb flag
• Git submodule ignored in the dvc dependency

I think that we can edit the issue template to recommend the patten "topic: description"

• dag: not accepting output files

You have more experience than me and probably you will have a better idea of how to write issue titles, I just want to start the conversation :)

[efiop]

Hi @MetalBlueberry ! Makes total sense! We try to stick to the standard topic: description, but looks like not everyone is used to such naming and we used to edit the titles but then just gave up unless the title is too random/confusing. Adding that to the issue template makes a lot of sense to me. Let us know if you are keen on submitting a low-hanger PR for that 😉

[karajan1001]

I wonder what is the difference between a topic and a label? in permission?

[efiop]

@karajan1001 Correct, we can assign some default labes to some issue templates (e.g. bug/feature), but that's about it, the user won't be able to set other labels himself unless we decide to add like a bot to do that for him through some commands(e.g. /label testing). Issue names help to navigate the repo better too, so those are really complementary to each other. 🙂

[MetalBlueberry]

@efiop I will be glad to open a PR, but first, we need to agree on what "topic" means.

for example, if you find the CRLF issue #4658 What would be the best topic: description?

• add: incorrect hash calculation
• hash: CRLF is ignored during hash calculation
• add: CRLF and LF line endings cannot be modified after dvc add

If we do not define what a topic is, it will be still hard to find related issues. do you have any idea?

also giving a hint of what the description should be will help. In this case, I think the description for an issue should be the consequence of the issue. in the CRLF case, option 3 will be the best.

[karajan1001]

There are at least three kinds of issues.

1. Bugs or feature requests of some DVC command, for example dvc add, dvc dag, etc... Here we can use the command name as the topic name.
2. Bugs or refactoring of a DVC module, like output, repo, remote. (we can also consider class 1 to be a special form of this) In this situation, we can use the module name.
3. Other things, maybe something like Docker image request. These issues are too flexible, hard to group ( In a text classification task we usually group them into the others class).

Another thing to be considered is that many of the issues might belong to multi-classes. That is to say, it is a multi-label classification problem.

[efiop]

@MetalBlueberry Agreed. And as @karajan1001 pointed out, the topic might depend on the depth of the knowledge that the issue creator has. But the general format of topic: description makes a lot of sense.

[MetalBlueberry]

@efiop I think that we can give some hints of how to define a topic in a way that doesn't require technical knowledge. If we stick to the proposal from @karajan1001 I think almost everyone will be able to assign a topic that will match what others expect even if they do not have technical knowledge.

the description is the hardest part.

• For bugs I will recommend writing what you see. not what you think is broken (some fake issues as examples)
  • dvc repro: metrics are uploaded to remote when cache is false.
  • dvc push: HTTP remote timeout
  • dvc pull: is slow on large directories.
  • dvc repro: cache false is ignored
  • dvc push: timeout value is too small
  • dvc pull: downloads files one by one
• For refactoring, the user already will have the knowledge to write a good description
• For requests, just describe what you want.

I think bugs are the most important part to standardized

let's wait to see of someone has something to add to this issue before creating the merge request.

[efiop]

@MetalBlueberry Good stuff! I would only remove the dvc prefix from the topic. So

• repro: metrics are uploaded to remote when cache is false
• push: HTTP remote timeout
• pull: is slow on large directories

[efiop]

Closing as stale.