|
|
# How and why are multiple forges used in the development life cycle of a given software?
|
|
|
|
|
|
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?
|
|
|
|
|
|
### The forge ecosystem
|
|
|
|
|
|
The interviewees use multiple forges for a variety of reasons but they mainly work on their software development project on a single forge. In the past years they came to experience and know about a wide variety of forges (GitHub, GitLab, Gitea, Phabricator, SourceHut, Heptapod, redmine, etc.) (ref. AR, CJ, CP, DA, DO, GR, MA, NA, PO, ZA). All of them have (or had in the past) a GitHub account and they acknowledge the monopolistic position it occupies because it hosts the majority of Free Software projects (ref. ZA44) (ref. DA54) (ref. MA67) (ref. DO61) (ref. GR39). Although they are concerned and have reservations about GitHub (ref. NA93) (ref. DA45) (ref. MA64) (ref. CP57), none of them refuse to use it (ref. PO80). The Free Software forges (GitLab CE, Gitea) are considered to be quality software that can easily be installed and maintained (ref. CP19). In the past years, the number of self-hosted forges instances grew substantially (ref. GR93). However the interviewees noticed that only a few are open to the general public (ref. MA4) (ref. CP57) (ref. GR75): most of them have a specific focus (ref. CP57). For instance the [GitLab CE instance of Gnome](https://gitlab.gnome.org/).
|
|
|
|
|
|
* **CP19**: "We converge towards the notion of 'I have a software component and it runs'".
|
|
|
* **CP57**: "[...] as any respectable Free Software developer trying to minimize their internal conflicts [...] you cannot be on GitHub nor GitLab.com"
|
|
|
* **CP57**: "If you look [...] for publicly available forges, there are not many."
|
|
|
* **CP57**: "[...] with my clients, I had lots of difficulties. [...]. I came to the conclusion that I had to manage my own forge."
|
|
|
* **DA54**: "I'm stuck because I can't upload on GitHub: [...] I don't have a GitHub account."
|
|
|
* **DO61**: "Nowadays if your project is not hosted on GitHub, it does not exist."
|
|
|
* **GR39**: "What made me a little uncomfortable [...] is that a GitHub project with 100 stars is automatically accepted by Open Collective. When a project is not on GitHub, there is a need to explain"
|
|
|
* **GR75**: "On our [public forge] we wanted to only accept Free Software projects."
|
|
|
* **GR84**: "I took the thing that analyzes projects and repositories and transformed 'Possible if this is git' into 'Possible if it is Mercurial'"
|
|
|
* **GR93**: "[...] there are plenty of people who self-host a [forge] instance and they imported projects from BitBucket."
|
|
|
* **MA4**: "[forge] is free and dedicated to Free Software - a Free Software project can send us a request and be hosted for free, including CI."
|
|
|
* **MA64**: "[...] people who leave Git platforms such as GitLab/GitHub for [forge] (because [...] they want their data on french servers and not American servers[...]"
|
|
|
* **MA67**: "There are things we are generally forced to do on GitHub and there also is an aura of 'most Free Software projects are on GitHub'"
|
|
|
* **NA93**: "GitHub actions for example: I don't like that feature. It feels like a trap."
|
|
|
* **PO80**: "[...] this is a GNU project that is not intended to feed the Microsoft leviathan.
|
|
|
* **ZA44**: "The ecosystem is dominated by a small number of forges that are very very big. This is a problem."
|
|
|
|
|
|
Key takeaways:
|
|
|
|
|
|
* GitHub is in a monopolistic situation
|
|
|
* Developers have reservations about centralized forges but use them anyway
|
|
|
* There exists a diversity of easily self-hostable Free Software forges
|
|
|
* The number of self-hosted forges instances is growing rapidly
|
|
|
* Only a small number of self-hosted forges is open to the general public
|
|
|
|
|
|
### 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 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)).
|
|
|
|
|
|
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).
|
|
|
|
|
|
The forge features used by a software project as well as its scope depends on how many people work on it. Very large projects tend to use more features and some tiny projects only have a DVCS (ref. NA22).
|
|
|
|
|
|
* **AR14**: "[...] contributing to Free Software is not only about code, it is also creating bug reports"
|
|
|
* **AR17**: "[...] I participate in the forum to help the users of that software and, from my point of view, it participates in the promotion, the ecosystem around this software."
|
|
|
* **AR20**: "[...] there is tooling which is more or less industrialized to produce these packages [...] it is hosted somewhere, it runs somewhere [...] "
|
|
|
* **CJ44**: "But at least having the opportunity to carry over nicely the community and keep track of these multiple forks contributions, anything to facilitate the human need around the software."
|
|
|
* **DA30**: "If I had to [...] keep a software as it is [...] I would save: the codebase, issues, releases, discussions [...]"
|
|
|
* **DA35**: "[...] all that allows the CI to work (not just the results of the CI)."
|
|
|
* **DA52**: "The problem with working on both <projectB> on GitHub and <projectC> on a GitLab instance[...]"
|
|
|
* **MA18**: "[...] we should be able to provide CI integrated with [our forge] this year."
|
|
|
* **NA16**: "I maintain stable branches or releases in various build systems/operating systems. So I definitely see the release workflow as something that I as a developer need to be aware of and work on to improve and streamline it."
|
|
|
* **NA22**: "There are very big projects [...]. In such a project, you necessarily have the developers specializing in various components: maintenance and release are just one component of the project in that case."
|
|
|
* **PO39**: "I tend to define a very wide perimeter, in the sense that I write software to make the life of users easier[...]"
|
|
|
* **PO42**: "After two years in production, the initial discussions were forgotten. But when it is time to code they are important elements."
|
|
|
* **ZA19**: "[...] the bare minimum is not boolean: there is the code, then the code history, then issues and merge requests"
|
|
|
* **ZA22**: "[...] there are complex CI with complex configuration and loosing it would obviously be a problem [...]"
|
|
|
|
|
|
Key takeaways:
|
|
|
|
|
|
* A software project is not limited to the content of the DVCS
|
|
|
* DVCS and discussions around the evolution of the code (issues, merge/pull requests) are frequently considered part of the history of a software project
|
|
|
* The boundaries of a software project are fuzzy
|
|
|
* Larger projects use more forge features
|
|
|
|
|
|
## Emerging themes
|
|
|
|
|
|
### Software project import/export and migration
|
|
|
|
|
|
A migration is a one shot operation (ref. GR110) that consists of moving a software project from a forge to another forge. The interviewees had 10+ years of experience in Free Software development and migrated projects more than once.
|
|
|
|
|
|
In all cases part of the data was lost (users, issues, cross references, discussions on forums or mailing lists, etc.) (ref. AR70) (ref. NA87) (ref. MA58) (ref. CP59) (ref. GR24) . Data was not lost because the migration failed: the person responsible for the migration knew that it could not preserve all the data. In some cases the features of the forges were different and it was non trivial to figure out how the development workflow would change. (ref. ZA56) (ref. ZA59) (ref. AR40). These problems delayed their decision to proceed with the migration but they eventually decided to accept the loss and move on (ref. AR70) (ref. PO75) (ref. NA90) (ref. DA85) (ref. CP59) (ref. GR121). Once the migration was done, the project was sometime preserved on the former forge but there was no turning back. The data was manually reconstructed later: users created new accounts, the new issue tracker was re-populated over time, etc. The motivation to migrate a project despite the problems it creates is, for most projects, the shutdown of the forge that hosts them ([bitbucket deprecation of Mercurial](https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket) (ref. MA17) (ref. GR21), [code.google.com](https://code.google.com/archive/) etc. (ref. DA88) (ref. CP55)).
|
|
|
|
|
|
The forge maintainers and developers interviewed did not remember users complaining about data loss (ref. MA55) (ref. CP53) (ref. GR101). And they did not mention asking for help when they were considering a migration.
|
|
|
|
|
|
* **AR40**: "We learned things about how git works. And that it was difficult to make mirrors [with Mercurial] and to do the mapping with models that are a little different."
|
|
|
* **AR70**: "Instead of '[redacted] wrote that' it was written 'Migration bot'"
|
|
|
* **AR70**: "when Phabricator was switched of we did not keep the history of all discussions on code review. I know for discussing this with other projects that is was a blocker for their migration to something else."
|
|
|
* **CP53**: "And apparently (because I did not use it myself, users told me about it), it works well."
|
|
|
* **CP55**: "A year or two ago, there were a significant number of migrations: framagit announced they would shutdown and there were migrations."
|
|
|
* **CP59**: "In the case of a client's project I lost the users: it was not a catastrophe but it was unpleasant."
|
|
|
* **CP59**: "With GitLab CE, if you are not root on the platform, you loose the identifiers of the author of the issues."
|
|
|
* **DA85**: "[...] discussions that happened on the old forge were lost."
|
|
|
* **DA88**: "On the gna.org forge [...] despite a one year advance warning [...] they came back years later and realized their project was lost."
|
|
|
* **GR101**: "Q: Did people ask for help with the import? A: In theory that was a possibility but it never happened."
|
|
|
* **GR110**: "Once they switch from one to the other, they do an import once and for all and all developers follow."
|
|
|
* **GR121**: "Mapping users is a problem that is almost impossible to solve. [...] With BitBucket it did not work well, we finally gave up entirely [...]"
|
|
|
* **GR21**: "[...] we had to salvage projects from BitBucket because it stopped supporting Mercurial."
|
|
|
* **GR24**: "The projects often have a history dated back 10/15 years and had chaotic beginning and they often trigger rare problems."
|
|
|
* **MA17**: "We knew that would happen because they were not invested in Mercurial for a long time and their support was not incomplete."
|
|
|
* **MA55**: "The first imports were done manually but then hundreds of projects arrived and were managed by the users, not by system administrators."
|
|
|
* **MA58**: "A fundamental problem we had was: how do we map users? A user on BitBucket makes a comment and is associated with an email, an avatar, permissions: when they are imported in GitLab, these users are not known and the question 'to whom does this comment belong' is left unanswered."
|
|
|
* **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."
|
|
|
* **ZA59**: "It is a real problem because there is no equivalence between the forges, because of this conceptual difference."
|
|
|
|
|
|
Key takeaways:
|
|
|
|
|
|
* Migration always implies data and/or feature loss
|
|
|
* Migration lossage is not a topic that is frequently discussed
|
|
|
* It is not uncommon for a software project to migrate from one forge to another
|
|
|
* Migrations are often caused by a forge shutdown
|
|
|
|
|
|
### Creating links between forges
|
|
|
|
|
|
The forges provide a wide range of services: DVCS repository (ref. ZA19) (ref. MA76), merge or pull requests, issues, CI (ref. GR154) are the most commonly used. Although integration with third party tools (chat, kanban, etc.) are available, they were only mentioned briefly during the interviews (ref. CP39) (ref. GR151). Home made scripts to perform tasks not provided by the forge out of the box (activity reports, communication with third party issue trackers) were more frequent (ref. PO110) (ref. NA52) (ref. DA109) (ref. CP49) (ref. GR84). All scripts use a REST API, a feature available on all forges. One forge (now discontinued) implemented an interface similar to ActivityPub (i.e. using data as actions concepts). The other forge services: operations (Kubernetes, OpenStack), static pages, packages registry (Debian GNU/Linux, PyPI, etc.), CD were less familiar to the participants.
|
|
|
|
|
|
The interviewees were asked to explain how they keep track of the bugs they find in the dependencies of the project they work on (for instance the python modules). They all acknowledged that they need to track dependencies between Free Software projects for that purpose (ref. ZA32) (ref. AR53) (ref. PO50) (ref. NA60) (ref. DA52). And that it is common that it leads to using a forge different from theirs (refs ZA32).
|
|
|
|
|
|
It will also happen when introducing a workaround because of a bug in a dependency. The associated commit (or the issue) will contain the URL of the corresponding bug in the dependency. But curating these dependencies and noticing when the workaround should be removed relies on self discipline. Even when two projects co-exist on the same forge, there is no convenient way to link two issues together. For instance, when a notification is received about an issue on project A, it is up to the developer to figure out that they subscribed to this notification because another issue that depends on it in project B (ref. ZA45) (ref. PO56).
|
|
|
|
|
|
Here is a list of the forge features (most popular first) for which links are curated manually:
|
|
|
|
|
|
* DVCS repositories forks (refs. AR67) (ref. PO119) (ref. NA37) (ref. NA52) (ref. DA68) (ref. DO48)
|
|
|
* Individual issues (ref. AR56) (ref. PO53) (ref. NA37) (ref. NA52) (ref. DA52) (ref. MA82)
|
|
|
* Individual pull or merge requests (ref. ZA70) (ref. NA81) (ref. GR158)
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
* **A32**: "It often happens that by following the dependency chain [...] it leads to a forge that is not mine"
|
|
|
* **AR53**: "[...] instead of taking the stable version or the version X of that package on PyPI or another PyPI instance, we boldly point to the SHA1 of the version found on a remote Git repository."
|
|
|
* **AR56**: "There is no tooling to handle these links, it is documented, it is a convention."
|
|
|
* **AR64**: "[...] to ensure stability we pin everything and then bots suggests upgrades that can be merged on a rolling basis."
|
|
|
* **AR67**: "He does the update the version [of the dependency] must be upgraded and the monkey patch breaks."
|
|
|
* **CP39**: "External issue trackers: Gitea handles that well and I use it to connect with the redmine of [organization]."
|
|
|
* **CP49**: "We use [the API] to produce activity reports."
|
|
|
* **DA109**: "It was a CLI tool to automate manual tasks by using the GitLab and Redmine API [...]"
|
|
|
* **DA52**: "<project B> has many dependencies. Some of them are hosted on other forges."
|
|
|
* **DA52**: "When there was a bug on <project C> with an impact on <projectB>, I was forced to open an issue on the GitLab of <projectC> and to keep track of it in the Redmine of <projectB> with a link."
|
|
|
* **DA68**: "[...] I have a copy of the Git repository of <projectB>. That allows me to manage the modifications I want to make, [...] without them being on my laptop. I would like that to be a mirror but it is not because GitLab CE does not have that functionality [...]"
|
|
|
* **DO48**: "[...] there was a component developed for a client, privately and we realize it is something generic that would make sense to publish. We ask the client for his opinion and if he agrees we do refactoring: copying pieces of code from a repository to another. There was no particular tooling, it was done manually [...]"
|
|
|
* **GR145**: "[...] we developed a Mercurial mirroring. The motivation to implement it was because we needed it for ourselves."
|
|
|
* **GR151**: "Readthedocs has a native GitLab integration: in the Readthedocs interface one can say the project is hosted on GitLab and it works [...]"
|
|
|
* **GR154**: "CI is part of what we want to develop: it is what people want nowadays."
|
|
|
* **GR158**: "[...] users [...] in our community would like to create stacked merge requests (the second merge request depends on the first) [...]""
|
|
|
* **MA76**: "[...] hg-git which is a bridge between Mercurial and Git [...]"
|
|
|
* **MA79**: "People regularly talk about having a version on [forge] and a mirror on GitHub [...]"
|
|
|
* **MA82**: "We end up having an issue tracker on GitLab that people use by mistake instead of using the official tracker of [project] [...]"
|
|
|
* **NA37**: "Issue tracking is done via Redmine and due to this "dual-forge" system, some pieces of information have to be duplicated on both forges."
|
|
|
* **NA52**: "We have some scripts to help developers automate repetitive tasks such as opening a backport issue in Redmine and opening a backport pull request in GitHub."
|
|
|
* **NA60**: "To use the RocksDB example, bugs in that dependency get fixed by applying a patch to the Ceph project's fork of the RocksDB git repo, and then triggering a new build. But since that means the fork has diverged from the upstream RocksDB project's source code, the patch has to be submitted to the RocksDB project, where it might end up being accepted in a modified form, or even rejected."
|
|
|
* **NA85**: "When I use Git to prepare a new branch for an update, and one or more downstream patches have made it into the upstream repo since the last update, I do it in such a way that Git automatically drops those patches. "
|
|
|
* **PO110**: "At April we have an ad-hoc bot to monitor the redmine activity"
|
|
|
* **PO119**: "[...] I use the tig viewer: I add forks I know as remotes in Git"
|
|
|
* **PO50**: "[...] I stumbled on a problem with the django-<plugin> dependency that is hosted on GitHub"
|
|
|
* **PO53**: "I added an hyperlink in a comment of the issue from <projectB> to the issue of the django-<plugin> project"
|
|
|
* **PO56**: "It is rather annoying, I check it periodically"
|
|
|
* **ZA32**: "A typical example is when a bug is discovered, not in your code but in a dependency"
|
|
|
* **ZA45**: "I want a comment in the code that allows me to understand, 6 or 12 months later, [...] if the workaround is still necessary or not"
|
|
|
* **ZA70**: "on BitBucket, I did not want to learn how to make pull requests and I sent patches attached to issues."
|
|
|
|
|
|
Key takeaways:
|
|
|
|
|
|
* Developers routinely and manually create links between projects living different forges
|
|
|
* The top forge features for which links are manually created are: DVCS, issues, pull or merge requests
|
|
|
* There exist at least one bot (dependabot) that creates links between projects
|
|
|
* Mirroring DVCS between forges is frequently used
|
|
|
|
|
|
### 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:
|
|
|
|
|
|
* Creating an account on a yet another forge is a friction that can be discouraging when it is only for the purpose of reporting a new bug (ref. ZA44) (ref. AR78) (ref. PO142) (ref. NA101) (ref. MA77)
|
|
|
* It is not possible to report a bug anonymously (or interact with a forge anonymously, in general) (ref. AR78) (ref. CJ44)
|
|
|
|
|
|
Developers are generally reluctant to change the user interface they use to work on a software project (ref. ZA32) (ref. PO47) (ref. PO79) (ref. NA108) (ref. DA97) (ref. MA17). To the extent that it may happen that a company is pressured by its developers to use a given forge because a number of them prefer its interface (ref. AR37) (ref. ZA51) (ref. DO16). Although it would be possible to make it so the interface of a forge mimics the interface of another, it is costly (ref. AR37).
|
|
|
|
|
|
* **AR37**: "The client pointed out: I have a JavaScript developer, he can do with GitHub - he did not say: he can do with Git - and he cannot contribute to your project unless he learns about Mercurial"
|
|
|
* **AR37**: "These were experiments for which we did not have a budget to finalize things, it was never completed."
|
|
|
* **AR78**: "I like [...] people who say hello 'I used the software in this way' and blockers preventing that are little stupid things like creating an account[...]"
|
|
|
* **AR78**: "I want to report a bug but there is no mail, I try to create an account and it turns out there is no button to create an account: I move on."
|
|
|
* **CJ44**: "If I want to open a mastodon bug, I have to go to GitHub and have an account there and open an issue."
|
|
|
* **DA97**: "[...] I'm very used to GitLab and it would take me time to extract myself from GitLab."
|
|
|
* **DO16**: "Obviously, the difficulty was that [this forge] was made by developers and geeks: the UX left a lot to be desired and this probably is what led to the quasi-death of it."
|
|
|
* **MA17**: "Mercurial is very good, even a little better than Git on this and this but we do not move to Git: we move to GitHub/GitLab"
|
|
|
* **MA77**: "[...] not needing to connect on five different forges to submit a merge-request to [project] would be fine with me."
|
|
|
* **NA101**: "I found that I had to first become a registered user of Gerrit in order to present it there for review. This was annoying because all I wanted to do was submit a small code change, not type my personal data into a form, click with my mouse on a button saying I agree to "terms and conditions", etc."
|
|
|
* **NA108**: "Well, actually, I do occasionally proxy for colleagues who come to me with patches for the Ceph spec file. Since the spec file is maintained upstream, these patches have to be submitted by someone with a GitHub account."
|
|
|
* **PO142**: "[What works well when using multiple forges?] The GitHub authentication."
|
|
|
* **PO47**: "[...] I used Fossil which has been a blocker to contribution: I endured Fossil and got so fed up that I stopped contributing to this particular software."
|
|
|
* **PO79**: "[...] SVN has a low entry bar for people who are not developers"
|
|
|
* **ZA11**: "If that's GitHub, I use the command line to create the pull-request, if it's GitLab, I use the web interface."
|
|
|
* **ZA32**: "[...] until recently I used a project hosted on BitBucket - which I only used for this purpose - and that was a nightmare: I was not used to do things with this forge."
|
|
|
* **ZA44**: "[...] I don't necessarily want to create an account just for the purpose of following a project hosted there [...]"
|
|
|
* **ZA51**: "The desire to proceed with the migration [to GitLab] is to take into account the needs of the developers."
|
|
|
|
|
|
Key takeaways:
|
|
|
|
|
|
* Creating multiple accounts is the primary source of friction when using multiple forges
|
|
|
* Developers usually have a strong opinion regarding the UI of the forge they use
|
|
|
|
|
|
## 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.
|
|
|
* **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. |