forgejo/discussions
49
43

Explicitly encourage merge requests to Forgejo #99

Closed
opened 2024年01月15日 17:22:52 +01:00 by fnetX · 3 comments
Owner
Copy link

I want to separate some thoughts from my comment in #96 (comment) to a separate issue. I have been thinking about this recently, and I want to share my mind about this and get your thoughts.

When managing contributors from Codeberg, there is often the question about where to send patches: Forgejo or Gitea. There are also people who are "neutral" to both projects. It might seem natural to send patches to the upstream project, because it will end in the downstream project (Forgejo), too.

However, I think that this is a false assumption. It does matter where patches are reviewed!

When sending patches to Forgejo, it does not bring immediate disadvantages. Since patches are currently actively upstreamed, they also benefit Gitea users currently. This neutralizes my only argument in favour of sending patches to Gitea.

But there are further advantages:

Sending patches to Forgejo makes the review open: Instead of requiring users to log in to proprietary platforms, the review on Forgejo can be open to more contributors, while reviews in the Gitea circles actively locks out the Forgejo team members from participating. People who do not want to use Codeberg will still have the opportunity for the review when patches are being upstreamed. Also, several Gitea maintainers do have accounts on Codeberg and occasionally participate in conversations here.

Forgejo's review makes a patch pass more eyes: Due to the nature of upstreaming the PRs, having content reviewed in Forgejo first enables more eyes to have a look.

Involving Forgejo maintainers in the review enables equal rights: When patches are submitted to Forgejo, it allows the Forgejo maintainers to position themselves on a patch earlier. It is the way to give both projects equal rights in terms of review.

Get an idea about actual Forgejo contributions: Several contributions to Gitea are supported by Forgejo's work. There are people who claim to side with Forgejo, however, their activity is only visible in the form of contributions to Gitea. There are also many contributions that originate from design discussions and reported bugs in Forgejo's issue trackers. While they sometimes cross-reference the origin in the pull request description, it is not easy to identify how much human resources are available on either side. Last but not least, since many Forgejo contributions result in upstreaming attempts, more activity becomes apparent in Gitea's spaces due to the additional pull requests. Sending Forgejo conributions to Forgejo makes it visible that people are working on improving this service.

Collect comments and concerns in a central place: The Forgejo maintainers still have opinions and concerns regarding the Gitea development. They also spot problems and mistakes, but they are not able to add them to the pull request. Instead, they are often scattered in the chats, in issue comments and other places. I believe that it will be valuable to have them collected in a central place for evaluation.

This is not a call for Gitea contributors to get active in Forgejo. I respect their choice about which project to support. However, I would like to encourage everyone who is either an explicit contributor to Forgejo or "neutral" between both projects to consider becoming more active within Forgejo, because I believe that directing patches to Gitea has negative impact on Forgejo.

I want to separate some thoughts from my comment in https://codeberg.org/forgejo/discussions/issues/96#issuecomment-1505612 to a separate issue. I have been thinking about this recently, and I want to share my mind about this and get your thoughts. When managing contributors from Codeberg, there is often the question about where to send patches: Forgejo or Gitea. There are also people who are "neutral" to both projects. It might seem natural to send patches to the upstream project, because it will end in the downstream project (Forgejo), too. However, I think that this is a false assumption. **It does matter where** patches are reviewed! When sending patches to Forgejo, it does not bring immediate disadvantages. Since patches are currently actively upstreamed, they also benefit Gitea users currently. This neutralizes my only argument in favour of sending patches to Gitea. But there are further advantages: **Sending patches to Forgejo makes the review open:** Instead of requiring users to log in to proprietary platforms, the review on Forgejo can be open to more contributors, while reviews in the Gitea circles actively locks out the Forgejo team members from participating. People who do not want to use Codeberg will still have the opportunity for the review when patches are being upstreamed. Also, several Gitea maintainers do have accounts on Codeberg and occasionally participate in conversations here. **Forgejo's review makes a patch pass more eyes:** Due to the nature of upstreaming the PRs, having content reviewed in Forgejo first enables more eyes to have a look. **Involving Forgejo maintainers in the review enables equal rights:** When patches are submitted to Forgejo, it allows the Forgejo maintainers to position themselves on a patch earlier. It is the way to give both projects equal rights in terms of review. **Get an idea about actual Forgejo contributions:** Several contributions to Gitea are supported by Forgejo's work. There are people who claim to side with Forgejo, however, their activity is only visible in the form of contributions to Gitea. There are also many contributions that originate from design discussions and reported bugs in Forgejo's issue trackers. While they sometimes cross-reference the origin in the pull request description, it is not easy to identify how much human resources are available on either side. Last but not least, since many Forgejo contributions result in upstreaming attempts, more activity becomes apparent in Gitea's spaces due to the additional pull requests. Sending Forgejo conributions to Forgejo makes it visible that people are working on improving this service. **Collect comments and concerns in a central place:** The Forgejo maintainers still have opinions and concerns regarding the Gitea development. They also spot problems and mistakes, but they are not able to add them to the pull request. Instead, they are often scattered in the chats, in issue comments and other places. I believe that it will be valuable to have them collected in a central place for evaluation. This is not a call for Gitea contributors to get active in Forgejo. I respect their choice about which project to support. However, I would like to encourage everyone who is either an explicit contributor to Forgejo or "neutral" between both projects to consider becoming more active within Forgejo, because I believe that directing patches to Gitea has negative impact on Forgejo.

When sending patches to Forgejo, it does not bring immediate disadvantages

I would still qualify it as challenging (mainly because of the number of different branches).

Note that the documentation currently states the opposite: https://forgejo.org/docs/latest/developer/workflow/#dependency

It is better to contribute directly to the dependency instead of adding a commit to this branch but it is sometimes not possible, for instance when someone does not have a GitHub account. The author of the commit is responsible for rebasing and resolve conflicts. The ultimate goal of this branch is to be empty and it is expected that a continuous effort is made to reduce its content so that the technical debt it represents does not burden Forgejo long term.

So this issue can be directly "implemented" in the documentation (maybe gitea should be treated differently from other dependencies in the documentation).

> When sending patches to Forgejo, it does not bring immediate disadvantages I would still qualify it as challenging (mainly because of the number of different branches). Note that the documentation currently states the opposite: https://forgejo.org/docs/latest/developer/workflow/#dependency > It is better to contribute directly to the dependency instead of adding a commit to this branch but it is sometimes not possible, for instance when someone does not have a GitHub account. The author of the commit is responsible for rebasing and resolve conflicts. The ultimate goal of this branch is to be empty and it is expected that a continuous effort is made to reduce its content so that the technical debt it represents does not burden Forgejo long term. So this issue can be directly "implemented" in the documentation (maybe `gitea` should be treated differently from other dependencies in the documentation).
Author
Owner
Copy link

Thank you for pointing this out. The actionable part of my proposal is to find such places and update them accordingly, and maybe add an explicit call to encourage contributions. I am aware that we do not currently make the call and rather indicate the opposite is desired. On the other hand, there is confusion about some community members contributing to Gitea instead of Forgejo. We should make our call consistent.

Thank you for pointing this out. The actionable part of my proposal is to find such places and update them accordingly, and maybe add an explicit call to encourage contributions. I am aware that we do not currently make the call and rather indicate the opposite is desired. On the other hand, there is confusion about some community members contributing to Gitea instead of Forgejo. We should make our call consistent.
Author
Owner
Copy link

I think this is no longer an issue. People interested in Forgejo are now contributing in the right place.

I think this is no longer an issue. People interested in Forgejo are now contributing in the right place.
Sign in to join this conversation.
No Branch/Tag specified
No results found.
No results found.
Labels
Clear labels
User research - Accessibility
Requires input about accessibility features, likely involves user testing.
User research - Blocked
Do not pick as-is! We are happy if you can help, but please coordinate with ongoing redesign in this area.
User research - Community
Community features, such as discovering other people's work or otherwise feeling welcome on a Forgejo instance.
User research - Config (instance)
Instance-wide configuration, authentication and other admin-only needs.
User research - Errors
How to deal with errors in the application and write helpful error messages.
User research - Filters
How filter and search is being worked with.
User research - Future backlog
The issue might be inspiring for future design work.
User research - Git workflow
AGit, fork-based and new Git workflow, PR creation etc
User research - Labels
Active research about Labels
User research - Moderation
Moderation Featuers for Admins are undergoing active User Research
User research - Needs input
Use this label to let the User Research team know their input is requested.
User research - Notifications/Dashboard
Research on how users should know what to do next.
User research - Rendering
Text rendering, markup languages etc
User research - Repo creation
Active research about the New Repo dialog.
User research - Repo units
The repo sections, disabling them and the "Add more" button.
User research - Security
User research - Settings (in-app)
How to structure in-app settings in the future?
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
forgejo/discussions#99
Reference in a new issue
forgejo/discussions
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?