This came up as a question during the SC21 tutorial. Someone was wondering about the fact that their fork had no issues tab. This is probably worth commenting on somewhere
1) In the common use case of using a fork to work on a contribution to another repo, you usually want to work with the upstream repo's issues rather than having your own set.
2) If you're forking in order to take a code in your own direction without expectation of merging upstream (a) you might actually want to copy rather than fork and (b) you probably want it to have its own issues.
It seems like the git (currently git-workflows) module is the most appropriate. This could also be relevant in the agile module. The advice there is to create a new repo, but I think we say you could use a fork of the h-n-w repo. Might want to tighten that up.
This came up as a question during the SC21 tutorial. Someone was wondering about the fact that their fork had no issues tab. This is probably worth commenting on somewhere
1) In the common use case of using a fork to work on a contribution to another repo, you usually want to work with the upstream repo's issues rather than having your own set. 2) If you're forking in order to take a code in your own direction without expectation of merging upstream (a) you might actually want to copy rather than fork and (b) you probably want it to have its own issues.
It seems like the git (currently git-workflows) module is the most appropriate. This could also be relevant in the agile module. The advice there is to create a new repo, but I think we say you could use a fork of the h-n-w repo. Might want to tighten that up.