... | ... | @@ -95,7 +95,7 @@ Key takeaways: |
|
|
|
|
|
### The scope of a software project
|
|
|
|
|
|
When a software project moves from a forge to another, it is not just about the content of the [DVCS](https://en.wikipedia.org/wiki/Distributed_version_control). Participants share the opinion that the past and present issues should also move with it: they are part of the history that helps future development. The issue tracker is also a place where users who do not contribute to the codebase can actively participate by reporting problems (ref. AR14) (ref. DA30).
|
|
|
When a software project moves from a forge to another, it is not just about the content of the Distributed Version Control System ([DVCS](https://en.wikipedia.org/wiki/Distributed_version_control)). Participants share the opinion that the past and present issues should also move with it: they are part of the history that helps future development. The issue tracker is also a place where users who do not contribute to the codebase can actively participate by reporting problems (ref. AR14) (ref. DA30).
|
|
|
|
|
|
When on-boarding new developers, it is useful to browse the discussions from older issues to understand how a particular part of the codebase came to be. This is also true for pull and merge requests, forums and mailing lists. Even the CI artifacts and the description of the CI: a complex pipeline that relies on features specific provided by a given forge (ref. ZA22) (ref. DA35) (ref. AM28) may be difficult to migrate to another forge that does not support them (for instance moving from [Travis](https://docs.travis-ci.com/user/tutorial/) to [GitLab CI](https://docs.gitlab.com/ce/ci/yaml/README.html)).
|
|
|
|
... | ... | |