|
|
# How and why are multiple forges used in the development life cycle of a given software?
|
|
|
## Executive Summary
|
|
|
|
|
|
The references to interview quotes are the first two letters of the directory in which the interview is stored and the line number.
|
|
|
The [fedeproxy project](https://forum.fedeproxy.eu/t/fedeproxy-full-description/13) started early 2021 to improve interoperability between software forges so that a Free Software developer can participate in any project, regardless of the forge where it is hosted. The ideal situation would be if all software forges were [federated](https://en.wikipedia.org/wiki/Federation_(information_technology)), but this is a very ambitious goal and fedeproxy chose an incremental approach. The user research is based on [10 interviews](https://jdittrich.github.io/userNeedResearchBook/#find-participants) with Free Software developers conducted between March and May 2021. They were analyzed by six Free Software developers and recommends to:
|
|
|
|
|
|
* **Focus on multi forges issues**. Developers manually add links in issues or commit comments to keep track of related issues that are located on different forges. They rely on their memory or conventions to connect the two. Fedeproxy can automate this workflow and provide activity notifications when it is lacking.
|
|
|
* **Leverage the desire of developers for a decentralized and federated ecosystem**. Although developers have agreed to the terms of service of centralized forges, they are unhappy about it. Making it easy for them to participate in fedeproxy would allow them to help making it happen sooner rather than later.
|
|
|
* **Create a User eXperience, not a User Interface**. Developers use the UI of the forge on which their project is hosted on a daily basis and are reluctant to use another UI. The UX provided by fedeproxy by must be embedded in the UI they currently use.
|
|
|
|
|
|
## Methodology
|
|
|
|
|
|
### [Create a user-focused how-and-why question based on the initial idea for the project](https://jdittrich.github.io/userNeedResearchBook/#questiontopics)
|
|
|
|
|
|
1. The initial idea is an online service that allows a user to interact with a software project hosted on one forge while using another forge.
|
|
|
1. The meaningful activity is to develop software.
|
|
|
1. How and why are multiple forges used in the development life cycle of a given software?
|
|
|
|
|
|
### [Find participants](https://jdittrich.github.io/userNeedResearchBook/#find-participants)
|
|
|
|
|
|
There are three personas (**Free Software developer**, **Forge developer**, **Forge maintainer**) and there needs to be at least three interviews for each persona.
|
|
|
|
|
|
#### [Free Software developer](https://lab.fedeproxy.eu/fedeproxy/ux/-/wikis/software-developer)
|
|
|
|
|
|
They are either serious hobbyists or professionals who participated in software development for several years. They have used more than one forge, simultaneously or because they had to migrate a project from one forge to another. The software they develop have dependencies to other software for which they either track issues related to features/bugs or provide patches.
|
|
|
|
|
|
#### [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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### [Forge maintainer](https://lab.fedeproxy.eu/fedeproxy/ux/-/wikis/forge-maintainer)
|
|
|
|
|
|
They are either independent system administrators or manager of an organization maintaining a forge that is either publicly available (such as https://forge.chapril.org/) or targeting a selected audience (such as https://lab.enough.community). They were involved in choosing the forge software and defining the production environment, backups, RGPD compliance, import and export policies.
|
|
|
|
|
|
### Intercept interviews
|
|
|
|
|
|
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.
|
|
|
|
|
|
### [Affinity mapping session](https://forum.fedeproxy.eu/t/user-research-affinity-mapping/140)
|
|
|
|
|
|
The six participants to the affinity mapping session got together on the 26th of May and had a thorough presentation of the fedeproxy project and an explanation of the goal of the session. It then started with individual activities:
|
|
|
|
|
|
* Read an interview transcript
|
|
|
* Copy / cut sentences from the interview transcript and group them in categories
|
|
|
* Stick the result on a large glass surface
|
|
|
|
|
|
When all interviews were analyzed in this way, all participatns got together and presented the groups of sentences they created, explaining why it made sense for them. When commonalities were discovered between groups, they were discussed, merged or renamed. In the end about twenty groups remained and there was an agreement that five of them were the most important one, the "emerging themes":
|
|
|
|
|
|
* The forge ecosystem
|
|
|
* The scope of a software project
|
|
|
* Software project import/export and migration
|
|
|
* Creating links between forges
|
|
|
* User Interfaces
|
|
|
|
|
|
### Writing the report
|
|
|
|
|
|
The report is an explanation of the "emerging themes" that re-uses the sentences extracted from the interviews and put them in context. It does not reflect the full diversity of what the interviewees said: it only focuses on these themes.
|
|
|
|
|
|
## Report
|
|
|
|
|
|
In the following the references to interview quotes are the first two letters of the directory in which the interview is stored and the line number.
|
|
|
|
|
|
## What is a forge? What is a software project?
|
|
|
|
... | ... | @@ -164,7 +224,7 @@ Key takeaways: |
|
|
* There exist at least one bot (dependabot) that creates links between projects
|
|
|
* Mirroring DVCS between forges is frequently used
|
|
|
|
|
|
### User interfaces
|
|
|
### User Interfaces
|
|
|
|
|
|
Developers interact with a forge daily and the UI was a topic in all interviews. It ranges from interfaces with a low barrier on entry (such as the web interface) to those that impose a significant learning curve and a complicated setup such as a CLI. And all kind of heterogeneous tooling in between (ref. ZA11). Although there exist a few interfaces that allow interaction with multiple forges, they were not discussed. Two problems were mentioned and experienced first hand:
|
|
|
|
... | ... | @@ -199,7 +259,7 @@ Key takeaways: |
|
|
|
|
|
## Recommendations
|
|
|
|
|
|
* **Focus on multi forges issues**. Although DVCS are the main focus when working on projects hosted on different forges, it is also complex to improve. Issues is the second most frequently needed feature and is comparatively easier.
|
|
|
* **Leverage the desire of developers for a decentralized and federated ecosystem**. Although developers have agreed to the terms of service of centralized forges, they are unhappy about it. They have difficulties refusing to use them but they may be willing to help by participating actively in fedeproxy.
|
|
|
* **Focus on multi forges issues**. Developers manually add links in issues or commit comments to keep track of related issues that are located on different forges. They rely on their memory or conventions to connect the two. Fedeproxy can automate this workflow and provide activity notifications when it is lacking.
|
|
|
* **Leverage the desire of developers for a decentralized and federated ecosystem**. Although developers have agreed to the terms of service of centralized forges, they are unhappy about it. Making it easy for them to participate in fedeproxy would allow them to help making it happen sooner rather than later.
|
|
|
* **Create a User eXperience, not a User Interface**. Developers use the UI of the forge on which their project is hosted on a daily basis and are reluctant to use another UI. The UX provided by fedeproxy by must be embedded in the UI they currently use.
|
|
|
* **Do not require the user to create an account on every forge**, even for the purpose of federation. Although having an account on both forges is a requirement to link two issues, it must be transparent to the user otherwise it will drive early adopters away. |
|
|
* **Create a UX, not a UI**. Developers use the UI of the forge on a daily basis and are reluctant to use another UI or another webservice. The UX must be embedded in the UI they currently use. |