... | ... | @@ -24,7 +24,7 @@ They are either serious hobbyists or professionals who participated in software |
|
|
|
|
|
#### [Forge developer](https://lab.fedeproxy.eu/fedeproxy/ux/-/wikis/forge-developer)
|
|
|
|
|
|
They work (or worked) on a forge software. They are involved in defining new features, figuring out the user needs, either as independent contributors or as a company employee. They use the forge on which they are working on a daily basis, i.e. dogfooding. They have a good understanding of the User Interface and how it is defined as well as the backend supporting it. They are involved in release management, know how to analyze integration test failures and are conscious of the tradeoff involved in maintaining backward compatibility.
|
|
|
They work (or worked) on a forge software. They are involved in defining new features, figuring out the user needs, either as independent contributors or as a company employee. They use the forge on which they are working on a daily basis, i.e. dogfooding. They have a good understanding of the User Interface and how it is defined as well as the backend supporting it. They are involved in release management, know how to analyze integration test failures and are conscious of the trade-off involved in maintaining backward compatibility.
|
|
|
|
|
|
The developers working on forges that have developed a strategy to lock-in their users such as SourceForge, GitHub or GitLab enterprise are not considered. Their ultimate goal is either to prevent their users from using multiple forges or to only support one migration path: from other forges to their own. As a consequence their input would be strongly biased to favor their own needs: it would obscure the needs of the users instead of revealing them.
|
|
|
|
... | ... | @@ -36,7 +36,7 @@ They are either independent system administrators or manager of an organization |
|
|
|
|
|
The ten [users willing to participate ](https://jdittrich.github.io/userNeedResearchBook/#find-participants) in this research answered the interviews (roughly one hour each) and were recorded. Each interview was then transcribed, proofread and sent to them for review. Some participants agreed that they are [made available publicly](https://lab.fedeproxy.eu/fedeproxy/ux/-/wikis/home#interviews) which may prove useful in other contexts: they often contain valuable insights.
|
|
|
|
|
|
The majority of participants have (or had) links with [LogiLab](https://www.logilab.org/). This is worth mentionning and could have been avoided but that was discovered during the affinity mapping session, at the very late stage of User Research. It does not seem to introduce a bias and it was decided to not discard interviews because of that.
|
|
|
The majority of participants have (or had) links with [LogiLab](https://www.logilab.org/). This is worth mentioning and could have been avoided but that was discovered during the affinity mapping session, at the very late stage of User Research. It does not seem to introduce a bias and it was decided to not discard interviews because of that.
|
|
|
|
|
|
### [Affinity mapping session](https://forum.fedeproxy.eu/t/user-research-affinity-mapping/140)
|
|
|
|
... | ... | @@ -97,7 +97,7 @@ Key takeaways: |
|
|
|
|
|
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 onboarding 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)).
|
|
|
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)).
|
|
|
|
|
|
The scope of what defines a software is fuzzy (ref. ZA19) (ref. PO42) (ref. CJ44). and should be considered on a case by case basis (ref. PO39). It is a web of dependencies that are not confined to the boundaries of a forge (ref. AR17) (ref. NA16) (ref. DA52). It includes every data, web service and developer that is stored and put to work when the software project moves forward. As an example, a developer mentioned that when they want to modify a software they use on their machine "most of the time it is not installed in a way that allows modifications: the first step is to get the code. If it's a Debian package, I look into he package metadata to find the source code, if it is a Python project, I tend to look on PyPI: I rely on the package manager to locate the source code" (ref. ZA11). Another example is how the software is packaged and distributed as it often involves resources external to the forge (ref. AR20).
|
|
|
|
... | ... | @@ -155,7 +155,7 @@ The forge maintainers and developers interviewed did not remember users complain |
|
|
* **NA87**: "It didn't go well. In fact, it wasn't really a "migration" at all. I just took a snapshot of the latest state and pushed that to GitHub in a commit."
|
|
|
* **NA90**: "No, the easiest thing to do was to start from clean state. I didn't try to migrate anything, and whatever was on SourceForge just stayed there."
|
|
|
* **PO75**: "The project was not active, the issues, the wiki and the user accounts have not been migrated"
|
|
|
* **ZA56**: "[...] how to map the issues that are not related to a specific project, typically elements of a roadmap[...]. There is a series of things like that which are rather well managed in the Phabricator data model and that must be mapped into the more limited model of GitLab."
|
|
|
* **ZA56**: "[...] how to map the issues that are not related to a specific project, typically elements of a road-map[...]. There is a series of things like that which are rather well managed in the Phabricator data model and that must be mapped into the more limited model of GitLab."
|
|
|
* **ZA59**: "It is a real problem because there is no equivalence between the forges, because of this conceptual difference."
|
|
|
|
|
|
Key takeaways:
|
... | ... | @@ -181,7 +181,7 @@ Here is a list of the forge features (most popular first) for which links are cu |
|
|
|
|
|
Bots can establish a link without the need for the developer to intervene and notify the developer to make an executive decision such as merging a proposed modification created automatically (ref. NA37). For example [dependabot](https://github.com/dependabot) (which also [exists for GitLab](https://gitlab.com/dependabot-gitlab/dependabot)) curates the dependencies of a project regardless of the forge they are hosted on. (ref. AR64) But such bots are still very rare.
|
|
|
|
|
|
Mirroring DVCS repositories between forges is known to be used (ref. MA79) although just one of the interviewees mentioned using it (ref. GR145). It is the only mirroring capability in existing forges and in some cases is only partly implemented (for instance GitLab CE can push but not pull). In any case, such a mirroring implies one end is the source of truth and the other is readonly. It is different from what developers need to go through when submitting a merge/pull request for a DVCS that is mirrored on different forges.
|
|
|
Mirroring DVCS repositories between forges is known to be used (ref. MA79) although just one of the interviewees mentioned using it (ref. GR145). It is the only mirroring capability in existing forges and in some cases is only partly implemented (for instance GitLab CE can push but not pull). In any case, such a mirroring implies one end is the source of truth and the other is read-only. It is different from what developers need to go through when submitting a merge/pull request for a DVCS that is mirrored on different forges.
|
|
|
|
|
|
This user research did not collect any evidence of other forge features for which developers actively create links between projects that reside on different forges.
|
|
|
|
... | ... | |