Solutions to absorb the workload? #53

earl-warren commented 2023年08月24日 09:50:00 +02:00

In Forgejo, like most Free Software projects, there are more ideas and bug reports that people available to work on a concrete implementation or a fix. As a result, the list of issues grows.

How can this problem be resolved?

---

This is the continuation of a discussion that started in the Forgejo issue tracker

In Forgejo, like most Free Software projects, there are more ideas and bug reports that people available to work on a concrete implementation or a fix. As a result, the list of issues grows. How can this problem be resolved? --- This is the continuation of a discussion that started [in the Forgejo issue tracker](https://codeberg.org/forgejo/forgejo/issues/1318#issuecomment-1067959)

earl-warren commented 2023年08月24日 09:57:12 +02:00

In reply to this comment:

I think the disintegration of social media platforms, the acquisition of Github by Microsoft, and other recent events, are prompting a slow but steady exodus into decentralized alternatives. Hopefully interest will broaden for supporting use and development of projects such as Forgejo.

👍

I feel that if distributed forges may ever reach the point of seamless federated integration, then they would experience explosive growth in usage rates relative to centralized ones, which would of course prompt broader interest in development.

When that happens it will likely make it easier to find people willing to contribute. But without an active recruitment effort, it will not happen. There is this strange disconnect to reality that most Free Software project suffer from: it is assumed there is an infinite supply of developers even when there is evidence to the contrary. One striking example is VLC which has been supported by an extremely small team of developers over more than two decades. Although it is one of the most well know project in the world.

At the moment, I am lacking any strong suggestions for recruitment methods that may be successful in the near future.

Perhaps encouraging various maintainers for individual projects written in Go to migrate to Codeberg would enhance visibility within the community of potential contributors.

I must confess that, being a developer myself, reaching out to other people and asking for help is not my strong suit. As you have experienced today, the way I do it comes out wrong for the most part 😊

In [reply to this comment](https://codeberg.org/forgejo/forgejo/issues/1318#issuecomment-1068048): > I think the disintegration of social media platforms, the acquisition of Github by Microsoft, and other recent events, are prompting a slow but steady exodus into decentralized alternatives. Hopefully interest will broaden for supporting use and development of projects such as Forgejo. 👍 > I feel that if distributed forges may ever reach the point of seamless federated integration, then they would experience explosive growth in usage rates relative to centralized ones, which would of course prompt broader interest in development. When that happens it will likely make it easier to find people willing to contribute. But without an active recruitment effort, it will not happen. There is this strange disconnect to reality that most Free Software project suffer from: it is assumed there is an infinite supply of developers even when there is evidence to the contrary. One striking example is VLC which has been supported by an extremely small team of developers over more than two decades. Although it is one of the most well know project in the world. > At the moment, I am lacking any strong suggestions for recruitment methods that may be successful in the near future. > > Perhaps encouraging various maintainers for individual projects written in Go to migrate to Codeberg would enhance visibility within the community of potential contributors. I must confess that, being a developer myself, reaching out to other people and asking for help is not my strong suit. As you have experienced today, the way I do it comes out wrong for the most part 😊

KaKi87 commented 2023年08月24日 11:34:10 +02:00

Would you be willing to reach out to potential developers willing to implement this?

— @earl-warren in forgejo/forgejo#1318 (comment)

I don't think users who submit feature requests and bug reports should be asked that.

> Would you be willing to reach out to potential developers willing to implement this? — @earl-warren in https://codeberg.org/forgejo/forgejo/issues/1318#issuecomment-1067932 I don't think users who submit feature requests and bug reports should be asked that.

KaKi87 commented 2023年08月24日 11:37:03 +02:00

How can this problem be resolved?

You won't like the answer to that, and neither do I.

But, here it is :

• advertising on centralized social media ;
• making bounties.

> How can this problem be resolved? You won't like the answer to that, and neither do I. But, here it is : - advertising on centralized social media ; - making bounties.

caesar commented 2023年08月24日 13:09:38 +02:00

In a way it's a difficult situation: there will never be enough developer time to implement every feature that is requested. But I don't think that's necessarily a major problem – just because someone requests a feature doesn't make it a priority to implement it or mean the project is in some way failing if it doesn't. The issue serves as a record of that request, and if someone wants it enough they might come and implement it, or if it becomes popular maybe it will become a priority for contributors.

On the other hand, it can also be argued that it's not even desirable to implement every feature request. Just because somebody asks for something, doesn't make it a good feature. So indeed some work is needed, not on development necessarily at first, but on triaging feature requests, trying to understand if they fit with the goals and direction of the project, and potentially closing them if they do not. After all, for every change that someone asks for, there will potentially be others who want the exact opposite.
I don't think we should be afraid to close feature requests that don't fit with the goals of the project – the only problem is defining those goals and strategy...

In a way it's a difficult situation: there will _never_ be enough developer time to implement every feature that is requested. But I don't think that's necessarily a major _problem_ – just because someone requests a feature doesn't make it a priority to implement it or mean the project is in some way failing if it doesn't. The issue serves as a record of that request, and if someone wants it enough they might come and implement it, or if it becomes popular maybe it will become a priority for contributors. On the other hand, it can also be argued that it's _not even desirable_ to implement every feature request. Just because somebody asks for something, doesn't make it _a good feature_. So indeed some work is needed, not on development necessarily at first, but on triaging feature requests, trying to understand if they fit with the goals and direction of the project, and potentially closing them if they do not. After all, for every change that someone asks for, there will potentially be others who want the exact opposite. I don't think we should be afraid to close feature requests that don't fit with the goals of the project – the only problem is defining those goals and strategy...

caesar commented 2023年08月24日 13:13:06 +02:00

Regarding the recent spate of opened issues, a lot of them are minor UI tweaks where to be honest more time will probably be spent discussing them than would ever be spent on implementation...

Regarding the recent spate of opened issues, a lot of them are minor UI tweaks where to be honest more time will probably be spent _discussing_ them than would ever be spent on implementation...

earl-warren commented 2023年08月24日 14:22:53 +02:00

How can this problem be resolved?

You won't like the answer to that, and neither do I.

But, here it is :

• advertising on centralized social media ;

Given the core values of Forgejo I don't think it will ever be an option.

• making bounties.

That's actually an idea I like. There is funding too, that's not an obstacle. The roadblock here is to find someone willing to help and run such a bounty program.

> > How can this problem be resolved? > > You won't like the answer to that, and neither do I. > > But, here it is : > > - advertising on centralized social media ; Given the core values of Forgejo I don't think it will ever be an option. > - making bounties. That's actually an idea I like. There is funding too, that's not an obstacle. The roadblock here is to find someone willing to help and run such a bounty program.

earl-warren commented 2023年08月24日 14:25:22 +02:00

Would you be willing to reach out to potential developers willing to implement this?

— @earl-warren in forgejo/forgejo#1318 (comment)

I don't think users who submit feature requests and bug reports should be asked that.

That was an ill inspired suggestion on my part. For some reason, not entirely rational, I got the impression that it would be appealing in this particular circumstance.

> > Would you be willing to reach out to potential developers willing to implement this? > > — @earl-warren in https://codeberg.org/forgejo/forgejo/issues/1318#issuecomment-1067932 > > I don't think users who submit feature requests and bug reports should be asked that. That was an ill inspired suggestion on my part. For some reason, not entirely rational, I got the impression that it would be appealing in this particular circumstance.

earl-warren commented 2023年08月24日 14:26:39 +02:00

In a way it's a difficult situation...

Very well put.

> In a way it's a difficult situation... Very well put.

KaKi87 commented 2023年08月24日 14:35:47 +02:00

for every change that someone asks for, there will potentially be others who want the exact opposite

That's what settings are for.

• advertising on centralized social media ;

Given the core values of Forgejo I don't think it will ever be an option.

Yeah I know. Yet it's one that would work.

• making bounties.

That's actually an idea I like. There is funding too, that's not an obstacle. The roadblock here is to find someone willing to help and run such a bounty program.

Can't the Forgejo organization run this by itself ?

The issue author gives the money to Forgejo, Forgejo gives the money to the contributor.

EDIT : actually, what would be even better is that Codeberg would do it, so that all projects hosted there could benefit from it.

EDIT 2 : I also found Gitpay - Bounties for git issues solved, but I have no idea if it supports self-hosted projects.

> for every change that someone asks for, there will potentially be others who want the exact opposite That's what settings are for. > > - advertising on centralized social media ; > > Given the core values of Forgejo I don't think it will ever be an option. Yeah I know. Yet it's one that would work. > > - making bounties. > > That's actually an idea I like. There is funding too, that's not an obstacle. The roadblock here is to find someone willing to help and run such a bounty program. Can't the Forgejo organization run this by itself ? The issue author gives the money to Forgejo, Forgejo gives the money to the contributor. EDIT : actually, what would be even better is that Codeberg would do it, so that all projects hosted there could benefit from it. EDIT 2 : I also found [Gitpay - Bounties for git issues solved](https://gitpay.me/), but I have no idea if it supports self-hosted projects.

earl-warren commented 2023年08月24日 14:45:49 +02:00

The big question marks is: which individual will take the lead of such a bounty program? Once someone does, I do not foresee any significant difficulty.

The big question marks is: which individual will take the lead of such a bounty program? Once someone does, I do not foresee any significant difficulty.

earl-warren commented 2023年08月24日 14:50:22 +02:00

EDIT 2 : I also found Gitpay - Bounties for git issues solved, but I have no idea if it supports self-hosted projects.

Such a program cannot depend on a proprietary service. A lot of time and energy has been dedicated on making sure Forgejo does not depend on proprietary services. Independence is something that does not happen by chance, it is hard work, daily. Introducing new dependencies to proprietary services would be going in the wrong direction, IMHO.

Yeah I know. Yet it's one that would work.

It may be used as a tool to attract people and that may work. But it would also have a significant negative impact: the people running the bounty program would be required to use proprietary software. Which is exactly the opposite of what Forgejo is set to do.

> EDIT 2 : I also found Gitpay - Bounties for git issues solved, but I have no idea if it supports self-hosted projects. Such a program cannot depend on a proprietary service. A **lot** of time and energy has been dedicated on making sure Forgejo does not depend on proprietary services. Independence is something that does not happen by chance, it is hard work, daily. Introducing new dependencies to proprietary services would be going in the wrong direction, IMHO. > Yeah I know. Yet it's one that would work. It may be used as a tool to attract people and that may work. But it would also have a significant negative impact: the people running the bounty program would be required to use proprietary software. Which is exactly the opposite of what Forgejo is set to do.

KaKi87 commented 2023年08月24日 22:20:41 +02:00

Introducing new dependencies to proprietary services would be going in the wrong direction, IMHO.

Well, a financial institution is needed anyway, so whether it includes business logic or not, it is an unavoidable proprietary dependency of this project.

the people running the bounty program would be required to use proprietary software

I didn't necessarily meant for both options to be related, but in any case, yes, that's a requirement anyway, I know.

> Introducing new dependencies to proprietary services would be going in the wrong direction, IMHO. Well, a financial institution is needed anyway, so whether it includes business logic or not, it is an unavoidable proprietary dependency of this project. > the people running the bounty program would be required to use proprietary software I didn't necessarily meant for both options to be related, but in any case, yes, that's a requirement anyway, I know.

oliverpool commented 2023年08月24日 22:28:37 +02:00

As a result, the list of issues grows.

As already mentioned, I see 2 possibilities:

• better define the scope of Forgejo, so that some feature requests can be declined upfront (reducing the number of created issues)
• increase the number of people-hours working on this list (to resolve them faster) => https://codeberg.org/forgejo/sustainability/

I don't think that the monetary incentive will help much (personal impression after being involved in grant processes).

it is an unavoidable proprietary dependency of this project.

If there is a free (as in "free software") alternative, I think the proprietary dependency should not be promoted by Forgejo.

> As a result, the list of issues grows. As already mentioned, I see 2 possibilities: - better define the scope of Forgejo, so that some feature requests can be declined upfront (reducing the number of created issues) - increase the number of people-hours working on this list (to resolve them faster) => https://codeberg.org/forgejo/sustainability/ I don't think that the monetary incentive will help much (personal impression after being involved in grant processes). > it is an unavoidable proprietary dependency of this project. If there is a free (as in "free software") alternative, I think the proprietary dependency should not be promoted by Forgejo.

KaKi87 commented 2023年08月24日 22:58:52 +02:00

If there is a free (as in "free software") alternative

Is there such a thing as free financial institutions ?

> If there is a free (as in "free software") alternative Is there such a thing as free financial institutions ?

n0toose commented 2023年08月24日 23:01:52 +02:00

Is there such a thing as free financial institutions ?

For reference: LiberaPay, which is a service that is free- and open-source, uses either PayPal or Stripe as a payment processor / dependency.

> Is there such a thing as free financial institutions ? For reference: LiberaPay, which is a service that is free- and open-source, uses either PayPal or Stripe as a payment processor / dependency.

KaKi87 commented 2023年08月24日 23:03:43 +02:00

Yes, the donation management software, that is LiberaPay, is open, but the financial institution, that are PayPal & Stripe, aren't.

Yes, the donation management software, that is LiberaPay, is open, but the financial institution, that are PayPal & Stripe, aren't.

n0toose commented 2023年08月24日 23:11:51 +02:00

Yes, the donation management software, that is LiberaPay, is open, but the financial institution, that are PayPal & Stripe, aren't.

Sorry, I didn't express my idea properly: I think that this probably insinuates that this is as open as it could possibly get. I think that this is what @oliverpool meant, as in, the service, and not the financial institution.

> Yes, the donation management software, that is LiberaPay, is open, but the financial institution, that are PayPal & Stripe, aren't. Sorry, I didn't express my idea properly: I think that this probably insinuates that this is as open as it could possibly get. I think that this is what @oliverpool meant, as in, the *service*, and not the financial institution.

earl-warren commented 2023年08月24日 23:18:13 +02:00

There also is the low tech approach to not use any dedicated software for running a bounty program. Talking to people until someone is found. This is a long process but a fairly simple one. And I'm pretty sure nobody is doing that for any project: I've never been approached in this way, ever. I would not mind at all that some contributor of a Free Software project does. The chances of success are slim but I don't see why it would fail. There are other people willing to help. RIght? 😅

There also is the low tech approach to not use any dedicated software for running a bounty program. Talking to people until someone is found. This is a long process but a fairly simple one. And I'm pretty sure nobody is doing that for any project: I've **never** been approached in this way, ever. I would not mind at all that some contributor of a Free Software project does. The chances of success are slim but I don't see why it would fail. There are other people willing to help. RIght? 😅

caesar commented 2023年08月24日 23:50:40 +02:00

If there is a free (as in "free software") alternative

Is there such a thing as free financial institutions ?

Only crypto, which I think most of us here would probably prefer to avoid...

> > If there is a free (as in "free software") alternative > > Is there such a thing as free financial institutions ? Only crypto, which I think most of us here would probably prefer to avoid...

KaKi87 commented 2023年08月25日 04:31:51 +02:00

Only crypto, which I think most of us here would probably prefer to avoid...

I don't mind getting past the current controversies about cryptocurrencies, because these issues are only due to people not wanting to understand why cryptocurrency and the blockchain have been actually created and are supposed to be used.

But for the same reason, cryptocurrency is currently unusable in our everyday life, which means it's not a good way to pay people yet.

Which is why I specifically mentioned "financial institution", which cryptocurrency wallets aren't.

> Only crypto, which I think most of us here would probably prefer to avoid... I don't mind getting past the current controversies about cryptocurrencies, because these issues are only due to people not wanting to understand why cryptocurrency and the blockchain have been actually created and are supposed to be used. But for the same reason, cryptocurrency is currently unusable in our everyday life, which means it's not a good way to pay people yet. Which is why I specifically mentioned "financial institution", which cryptocurrency wallets aren't.

brainchild commented 2023年08月25日 05:44:36 +02:00

Just because somebody asks for something, doesn't make it a good feature.

Yes.

I don't think we should be afraid to close feature requests

No, but more refined triage is also available, through labels, compared simply to open versus closed status.

Some projects keep certain issues open, but mark them using labels as Needs discussion, or Requires redesign, or by tiers of priority.

Regarding the recent spate of opened issues... more time will probably be spent discussing them than would ever be spent on implementation...

In some cases, a project lead will consolidate may small related issues into a large one that can be handled under a single discussion and pull request. However, most project contributors dislike multiple requests or problems to be submitted by users under the same issue ticket, and so I generally avoid it.

> Just because somebody asks for something, doesn't make it _a good feature_. Yes. > I don't think we should be afraid to close feature requests No, but more refined triage is also available, through labels, compared simply to open versus closed status. Some projects keep certain issues open, but mark them using labels as *Needs discussion*, or *Requires redesign*, or by tiers of priority. > Regarding the recent spate of opened issues... more time will probably be spent _discussing_ them than would ever be spent on implementation... In some cases, a project lead will consolidate may small related issues into a large one that can be handled under a single discussion and pull request. However, most project contributors dislike multiple requests or problems to be submitted by users under the same issue ticket, and so I generally avoid it.

brainchild commented 2023年08月25日 06:15:29 +02:00

In Forgejo... there are more ideas and bug reports that people available to work... How can this problem be resolved?

You are probably seeking practical solutions for achieving results in the short term, but ultimately, the issue is a political one, related to broader attention from the media, and shifting attitude among the public.

As major social media platforms become increasingly blameworthy for broader problems, Fediverse solutions are rapidly developing traction. Mastadon and Lemmy instances, for example, are gaining users, following growing outrage against Twitter/X and Reddit.

Software forges are less relevant to most of the population compared to social media, but the number of users is large, and much of the population, even not involved in software development, by now has become familiar with Github.

Even if Forgejo would not achieve federated integration within the near future, all that prevents a coalition of instances of Forgejo from replacing Github as the leading host of open software is the lack of will from within the community to seek an alternative.

If Codeberg and Forgejo could position themselves within the public consensus as carrying the analogue relationship from Github, and if more projects began to migrate, then enthusiasm among potential contributors would be likely to expand at pace.

> In Forgejo... there are more ideas and bug reports that people available to work... How can this problem be resolved? > You are probably seeking practical solutions for achieving results in the short term, but ultimately, the issue is a political one, related to broader attention from the media, and shifting attitude among the public. As major social media platforms become increasingly blameworthy for broader problems, Fediverse solutions are rapidly developing traction. Mastadon and Lemmy instances, for example, are gaining users, following growing outrage against Twitter/X and Reddit. Software forges are less relevant to most of the population compared to social media, but the number of users is large, and much of the population, even not involved in software development, by now has become familiar with Github. Even if Forgejo would not achieve federated integration within the near future, all that prevents a coalition of instances of Forgejo from replacing Github as the leading host of open software is the lack of will from within the community to seek an alternative. If Codeberg and Forgejo could position themselves within the public consensus as carrying the analogue relationship from Github, and if more projects began to migrate, then enthusiasm among potential contributors would be likely to expand at pace.

earl-warren commented 2023年08月25日 09:10:52 +02:00

I wish that becomes a reality. For that to happen there is a pressing need of non-technical people doing concrete work in Forgejo. This is the number one blocker at present.

I wish that becomes a reality. For that to happen there is a pressing need of non-technical people doing concrete work in Forgejo. This is the number one blocker at present.

brainchild commented 2023年08月25日 10:04:02 +02:00

It would require leadership directing Forgejo into a partnership with Fedverse-oriented organizations.

It would require leadership directing Forgejo into a partnership with Fedverse-oriented organizations.

earl-warren commented 2023年08月25日 10:24:10 +02:00

That's one option indeed.

Just to clarify, I understand "leadership" in the sense "someone from the Forgejo community taking the lead". Not "a group of people leading Forgejo" which does not exist, because Forgejo is a community of people who are on an equal footing. Someone participating in discussions in the tracker and sharing their expertise as you do is as much in a "leadership" position as someone writing code or publishing releases.

That's one option indeed. Just to clarify, I understand "leadership" in the sense "someone from the Forgejo community taking the lead". Not "a group of people leading Forgejo" which does not exist, because Forgejo is a community of people who are on an equal footing. Someone participating in discussions in the tracker and sharing their expertise as you do is as much in a "leadership" position as someone writing code or publishing releases.

brainchild commented 2023年08月25日 10:32:23 +02:00

Yes, "leadership" in the generic sense, of a person or group respected among a larger group, for assuming a particular responsibility, and for performing it competently.

One or more individuals are needed who may coordinate common interests between the two groups, and who would have some influence within either.

Yes, "leadership" in the generic sense, of a person or group respected among a larger group, for assuming a particular responsibility, and for performing it competently. One or more individuals are needed who may coordinate common interests between the two groups, and who would have some influence within either.

KaKi87 commented 2023年08月25日 11:46:00 +02:00

Mastadon and Lemmy instances, for example, are gaining users, following growing outrage against Twitter/X and Reddit.

That won't ever be enough, though. Big tech will keep leading.

there is a pressing need of non-technical people doing concrete work in Forgejo

What kind of work ?

> Mastadon and Lemmy instances, for example, are gaining users, following growing outrage against Twitter/X and Reddit. That won't ever be enough, though. Big tech will keep leading. > there is a pressing need of non-technical people doing concrete work in Forgejo What kind of work ?

earl-warren commented 2023年08月25日 11:52:35 +02:00

I'm a little more optimistic. It is a David against Goliath kind of fight but I've always rooted for the underdog 😄

What kind of work ?

I'm not sure how to answer that question. All kind of non-technical work. The list would be very very long.

I'm a little more optimistic. It is a David against Goliath kind of fight but I've always rooted for the underdog 😄 > What kind of work ? I'm not sure how to answer that question. All kind of non-technical work. The list would be very very long.

caesar commented 2023年08月25日 12:35:35 +02:00

All kind of non-technical work. The list would be very very long.

Some examples might help to recruit people who can help out. Most tasks I can think of (eg documentation) do involve some level of technical know-how, but probably not full knowledge of the internals of the codebase. Triaging issues might be another example that requires less technical knowledge, but probably still some. Are those the kind of things you were thinking of?

> All kind of non-technical work. The list would be very very long. Some examples might help to recruit people who can help out. Most tasks I can think of (eg documentation) do involve some level of technical know-how, but probably not full knowledge of the internals of the codebase. Triaging issues might be another example that requires less technical knowledge, but probably still some. Are those the kind of things you were thinking of?

earl-warren commented 2023年08月25日 14:42:45 +02:00

Yes. Even less technical such as organizing a video conference. Assembling a panel of users and observing them for user research purposes. Moderation. Advancing the work on governance which slowed down in the past few months. Recording a presentation about Forgejo to explain it to potential users. Organizing a room on Forge at next FOSDEM. Adding and updating information about forges in Wikipedia and WIkidata And much more.

Yes. Even less technical such as organizing a video conference. Assembling a panel of users and observing them for user research purposes. Moderation. Advancing the work on governance which slowed down in the past few months. Recording a presentation about Forgejo to explain it to potential users. Organizing a room on Forge at next FOSDEM. Adding and updating information about forges in Wikipedia and WIkidata And much more.

KaKi87 commented 2023年08月25日 15:04:19 +02:00

Some examples might help to recruit people who can help out.

Exactly : regarding Forgejo, I'm mostly a non-technical person, so perhaps I can help with non-technical tasks. Not administrative duties though. But if there was a list, perhaps I'd find something I could do in there.

Triaging issues might be another example that requires less technical knowledge, but probably still some.

As well as a GitHub account to do the link between Forgejo and Gitea.

> Some examples might help to recruit people who can help out. Exactly : regarding Forgejo, I'm mostly a non-technical person, so perhaps I can help with non-technical tasks. Not administrative duties though. But if there was a list, perhaps I'd find something I could do in there. > Triaging issues might be another example that requires less technical knowledge, but probably still some. As well as a GitHub account to do the link between Forgejo and Gitea.

KaKi87 commented 2023年08月25日 15:06:45 +02:00

Yes. Even less technical such as organizing a video conference. Assembling a panel of users and observing them for user research purposes. Moderation. Advancing the work on governance which slowed down in the past few months. Recording a presentation about Forgejo to explain it to potential users. Organizing a room on Forge at next FOSDEM. Adding and updating information about forges in Wikipedia and WIkidata And much more.

Oops I didn't see your reply. But yeah, everything that requires people skills and producing content for end users are things I can't do either, I'm afraid. 😅

> Yes. Even less technical such as organizing a video conference. Assembling a panel of users and observing them for user research purposes. Moderation. Advancing the work on governance which slowed down in the past few months. Recording a presentation about Forgejo to explain it to potential users. Organizing a room on Forge at next FOSDEM. Adding and updating information about forges in Wikipedia and WIkidata And much more. Oops I didn't see your reply. But yeah, everything that requires people skills and producing content for end users are things I can't do either, I'm afraid. 😅

caesar commented 2023年08月25日 15:28:49 +02:00

Perhaps it would be a good idea to work on a list of such things that people could help out with, and publicise it – perhaps with a toot from the Forgejo fedi account or even a blog post (if anyone feels like writing one...).

One way of compiling such a list might be to open an issue (on this repo?) for each task, and assign a specific tag to it. Alternatively, perhaps just a single issue with a list of tasks, and then people could open issues for tasks they were interested in.

Perhaps it would be a good idea to work on a list of such things that people could help out with, and publicise it – perhaps with a toot from the Forgejo fedi account or even a blog post (if anyone feels like writing one...). One way of compiling such a list might be to open an issue (on this repo?) for each task, and assign a specific tag to it. Alternatively, perhaps just a single issue with a list of tasks, and then people could open issues for tasks they were interested in.

caesar commented 2023年08月25日 15:29:50 +02:00

For tasks which do involve working with the codebase, but might be more suited to new contributors who aren't deeply familiar with the codebase or perhaps with Go, we should probably have a good first issue tag on the forgejo/forgejo repo.

For tasks which do involve working with the codebase, but might be more suited to new contributors who aren't deeply familiar with the codebase or perhaps with Go, we should probably have a `good first issue` tag on the forgejo/forgejo repo.

caesar commented 2023年08月25日 15:31:48 +02:00

As well as a GitHub account to do the link between Forgejo and Gitea.

Not necessarily. Even triaging issues on the Forgejo repo would be a great start. Finding relevant upstream issues and linking them from here certainly helps, and doesn't require a GitHub account. Actually contributing upstream certainly isn't something required of every Forgejo contributor.

> As well as a GitHub account to do the link between Forgejo and Gitea. Not necessarily. Even triaging issues on the Forgejo repo would be a great start. Finding relevant upstream issues and linking them from here certainly helps, and doesn't require a GitHub account. Actually contributing upstream certainly isn't something required of every Forgejo contributor.

KaKi87 commented 2023年08月25日 17:04:12 +02:00

Finding relevant upstream issues and linking them from here certainly helps

Yes, but then someone has to keep the Forgejo issue updated when the Gitea issue is updated and vice versa.

And actually, I was mostly talking about creating Gitea issues when a Forgejo issue must be resolved upstream.

However, if those tasks really aren't necessary, then I guess I'd volunteer.

> Finding relevant upstream issues and linking them from here certainly helps Yes, but then someone has to keep the Forgejo issue updated when the Gitea issue is updated and vice versa. And actually, I was mostly talking about creating Gitea issues when a Forgejo issue must be resolved upstream. However, if those tasks really aren't necessary, then I guess I'd volunteer.

Gusted commented 2023年08月25日 22:52:12 +02:00

So I'm going to approach it from a technical standpoint and not focus on the human performance problem, because that's something I see but just don't have a good solution for.

I think the best way to absorb the workload is to make the pipeline from triaging a issue to actually merging the code for the issue as efficient as possible.

Triaging
I think triaging bugs is trivial, if the user report is clear and concise it should be obvious what the expected and current behavior is and if the current behavior is actually wrong, this is of course easier said for some problems than for those that occur in edge cases. To make this more efficient, I think we can adapt the use of the CODEOWNERS file that defines who maintains a particular feature or component in Forgejo, where someone could ping the more knowledgeable person about an unhandled problem and define the expected behavior.

Something that's just mostly human labor and cannot be made a lot more efficient is to get an reproducer, this really depends on the user reporting to explain what's going on.

However feature requests on the other hand is not quite trivial, there are a few main topics that Forgejo focuses on, which are outlined in the README, but it doesn't provide a roadmap or a clear line of what Forgejo wants to include and not and this can and I think is already causing for friction in feature request where time is being spent not working on discussing the feature request and understanding the use case but rather if it's actually worth doing.

I've already gave it away of what I think is important to make this more efficient is to define a clear plan and roadmap of what Forgejo wants to accomplish and define handles on how to decide if a feature request should be considered or not. I understand that this is easier said than done, as we're basically predicting feature requests and then already try to make a judgement if it's worth or not. As for that I think outlining certain in-depth technical principles can go a long way, a few examples:

• Forgejo should always prioritize git hosting, all the other features are second citizens.z
• Creating a issue and responding to a issue should always be accessible to people who solely created a account to do this.
• Forgejo should always be easy to install.

Development
Forgejo is a large codebase (3k files with ~300K lines of Go code and ~21K lines of javascript code) and has a lot of moving parts and, in my opinion, a pretty big chunk of undocumented code that can only be understood if you spend time looking at the code and playing around with it. But all of this assumes that someone even knows where to start. I would suggest that we design an ARCHITECTURE.md file for Forgejo that describes where certain types of code are, how they interact with each other, and some other high-level overview of the code. I hope this will also have the benefit of being more accessible to new contributors, so they can get a better overview of the codebase and make it feel less like magic.

Another part of the process that is too often overlooked is not creating test code or understanding how the tests works. The tests in Forgejo are 50% Go tests and 50% magic helper functions that are not documented. So I would also suggest creating a new document for developers on how to optimally write unit and integration tests in Forgejo and explain when to write unit tests and when integration tests are required.

I understand that it's fun to hack on a project without following a tutorial, but I think Forgejo has so many moving parts and features that only if you're really dedicated and have put in an unhealthy amount of hours can you create and slowly understand the codebase without helping hands from existing contributors.

Review process
I have already spoiled the fun of this section by mentioning the CODEOWNERs file. While it's not a problem at the moment, since the existing contributors know more or less intuitively who to ask as a reviewer, starting to document who knows what is a good start so that this doesn't become a problem in the future.

One suggestion would be that we add a template for pull requests so that the pull requests include some background information, past behavior, new behavior, some additional information, and references to issues or previous commits in a concise way so that reviewers know what they are getting into before they focus on the code and start reviewing.

Backporting
This is just a small nit of mine, but I think backporting can mostly be automated, the forgejo/docs repository already does this.

Closing remarks
Looking this over, and I want to note that this is anything revolutionary or experimental, but mostly applying existing solutions and techniques to the pipeline to improve its efficiency and therefor I'm optimistic in accomplishing this.

So I'm going to approach it from a technical standpoint and not focus on the human performance problem, because that's something I see but just don't have a good solution for. I think the best way to absorb the workload is to make the pipeline from triaging a issue to actually merging the code for the issue as efficient as possible. **Triaging** I think triaging bugs is trivial, if the user report is clear and concise it should be obvious what the expected and current behavior is and if the current behavior is actually wrong, this is of course easier said for some problems than for those that occur in edge cases. To make this more efficient, I think we can adapt the use of the CODEOWNERS file that defines who maintains a particular feature or component in Forgejo, where someone could ping the more knowledgeable person about an unhandled problem and define the expected behavior. Something that's just mostly human labor and cannot be made a lot more efficient is to get an reproducer, this really depends on the user reporting to explain what's going on. However feature requests on the other hand is not quite trivial, there are a few main topics that Forgejo focuses on, which [are outlined in the README](https://codeberg.org/forgejo/forgejo#what-does-forgejo-offer), but it doesn't provide a roadmap or a clear line of what Forgejo wants to include and not and this can and I think is already causing for friction in feature request where time is being spent not working on discussing the feature request and understanding the use case but rather if it's actually worth doing. I've already gave it away of what I think is important to make this more efficient is to define a clear plan and roadmap of what Forgejo wants to accomplish and define handles on how to decide if a feature request should be considered or not. I understand that this is easier said than done, as we're basically predicting feature requests and then already try to make a judgement if it's worth or not. As for that I think outlining certain in-depth technical principles can go a long way, a few examples: - Forgejo should always prioritize git hosting, all the other features are second citizens.z - Creating a issue and responding to a issue should always be accessible to people who solely created a account to do this. - Forgejo should always be easy to install. **Development** Forgejo is a large codebase (3k files with ~300K lines of Go code and ~21K lines of javascript code) and has a lot of moving parts and, in my opinion, a pretty big chunk of undocumented code that can only be understood if you spend time looking at the code and playing around with it. But all of this assumes that someone even knows where to start. I would suggest that we design an [ARCHITECTURE.md](https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html) file for Forgejo that describes where certain types of code are, how they interact with each other, and some other high-level overview of the code. I hope this will also have the benefit of being more accessible to new contributors, so they can get a better overview of the codebase and make it feel less like magic. Another part of the process that is too often overlooked is not creating test code or understanding how the tests works. The tests in Forgejo are 50% Go tests and 50% magic helper functions that are not documented. So I would also suggest creating a new document for developers on how to optimally write unit and integration tests in Forgejo and explain when to write unit tests and when integration tests are required. I understand that it's fun to hack on a project without following a tutorial, but I think Forgejo has so many moving parts and features that only if you're really dedicated and have put in an unhealthy amount of hours can you create and slowly understand the codebase without helping hands from existing contributors. **Review process** I have already spoiled the fun of this section by mentioning the CODEOWNERs file. While it's not a problem at the moment, since the existing contributors know more or less intuitively who to ask as a reviewer, starting to document who knows what is a good start so that this doesn't become a problem in the future. One suggestion would be that we add a template for pull requests so that the pull requests include some background information, past behavior, new behavior, some additional information, and references to issues or previous commits in a concise way so that reviewers know what they are getting into before they focus on the code and start reviewing. **Backporting** This is just a small nit of mine, but I think backporting can mostly be automated, the [forgejo/docs](https://codeberg.org/forgejo/docs) repository already does this. **Closing remarks** Looking this over, and I want to note that this is anything revolutionary or experimental, but mostly applying existing solutions and techniques to the pipeline to improve its efficiency and therefor I'm optimistic in accomplishing this.

caesar commented 2023年08月25日 23:04:51 +02:00

Forgejo is a large codebase (3k files with ~300K lines of Go code and ~21K lines of javascript code) and has a lot of moving parts and, in my opinion, a pretty big chunk of undocumented code that can only be understood if you spend time looking at the code and playing around with it. But all of this assumes that someone even knows where to start.

This is absolutely true, and personally I find it a very hard codebase to find my way around. I'm sure it's exacerbated by my unfamiliarity with Go conventions, but the almost complete lack of comments / code documentation certainly doesn't help.

I would suggest that we design an ARCHITECTURE.md file for Forgejo that describes where certain types of code are, how they interact with each other, and some other high-level overview of the code. I hope this will also have the benefit of being more accessible to new contributors, so they can get a better overview of the codebase and make it feel less like magic.

This would be an absolutely enormous help to people like me who are not deeply familiar with the codebase. I think having something like that available would boost my productivity enormously and I'm sure the same is true of other new contributors (although I've been involved in Forgejo from the beginning I very much consider myself a new contributor in terms of the Forgejo/Gitea codebase).

Another part of the process that is too often overlooked is not creating test code or understanding how the tests works. The tests in Forgejo are 50% Go tests and 50% magic helper functions that are not documented. So I would also suggest creating a new document for developers on how to optimally write unit and integration tests in Forgejo and explain when to write unit tests and when integration tests are required.

Likewise, this would be extremely helpful and would certainly result in better quality tests and, therefore, better quality code.

> Forgejo is a large codebase (3k files with ~300K lines of Go code and ~21K lines of javascript code) and has a lot of moving parts and, in my opinion, a pretty big chunk of undocumented code that can only be understood if you spend time looking at the code and playing around with it. But all of this assumes that someone even knows where to start. This is absolutely true, and personally I find it a very hard codebase to find my way around. I'm sure it's exacerbated by my unfamiliarity with Go conventions, but the almost complete lack of comments / code documentation certainly doesn't help. > I would suggest that we design an ARCHITECTURE.md file for Forgejo that describes where certain types of code are, how they interact with each other, and some other high-level overview of the code. I hope this will also have the benefit of being more accessible to new contributors, so they can get a better overview of the codebase and make it feel less like magic. This would be an _absolutely enormous_ help to people like me who are not deeply familiar with the codebase. I think having something like that available would boost my productivity enormously and I'm sure the same is true of other new contributors (although I've been involved in Forgejo from the beginning I very much consider myself a new contributor in terms of the Forgejo/Gitea codebase). > Another part of the process that is too often overlooked is not creating test code or understanding how the tests works. The tests in Forgejo are 50% Go tests and 50% magic helper functions that are not documented. So I would also suggest creating a new document for developers on how to optimally write unit and integration tests in Forgejo and explain when to write unit tests and when integration tests are required. Likewise, this would be extremely helpful and would certainly result in better quality tests and, therefore, better quality code.

brainchild commented 2023年08月26日 04:04:53 +02:00

I have two further thoughts, though again not directly addressing the question.

The first is for the project to begin operating a fully featured web forum.

Presently, the locations available for discussion seem to be the current "Discussions" meta-project, and an Element chat room. Neither is suitable for broad community engagement, as would help expose the project and keep it engaged in the broader ecosystem.

A full forum seems to be needed instead or in addition, with support not only for discussions by topic, but also categories and announcements.

I am imagining three broad sections of categories, for user support, design discussion, and community engagement. The last may serve for discussion related to my earlier comments, about developing relationships and leadership between the project and those presently within the Fediverse family.

My second thought is to engage with institutions, such as research institutes and large software foundations (e.g. Linux, Gnome, Apache), and encourage them to operate their own instances of Forgejo. At first, they might seek simply to provide alternatives sites for independent projects that might otherwise be hosted on Github, but eventually they also might migrate their own projects into the site.

If important software projects developed by recognized groups were increasingly exposed publicly as maintaining their central repositories on sites that operate Forgejo, then greater visibility and enthusiasm for the project would be likely follow.

I have two further thoughts, though again not directly addressing the question. The first is for the project to begin operating a fully featured web forum. Presently, the locations available for discussion seem to be the current "Discussions" meta-project, and an Element chat room. Neither is suitable for broad community engagement, as would help expose the project and keep it engaged in the broader ecosystem. A full forum seems to be needed instead or in addition, with support not only for discussions by topic, but also categories and announcements. I am imagining three broad sections of categories, for user support, design discussion, and community engagement. The last may serve for discussion related to my earlier comments, about developing relationships and leadership between the project and those presently within the Fediverse family. My second thought is to engage with institutions, such as research institutes and large software foundations (e.g. Linux, Gnome, Apache), and encourage them to operate their own instances of Forgejo. At first, they might seek simply to provide alternatives sites for independent projects that might otherwise be hosted on Github, but eventually they also might migrate their own projects into the site. If important software projects developed by recognized groups were increasingly exposed publicly as maintaining their central repositories on sites that operate Forgejo, then greater visibility and enthusiasm for the project would be likely follow.

caesar commented 2023年08月26日 14:17:40 +02:00

a fully featured web forum

Slightly off topic, but in the long run I would love it if forgejo/forgejo#410 covered this use case... this is really something that in my opinion should be integrated into Forgejo as something that a lot of projects need. Technically it's mostly a case of repurposing issues and so (famous last words) is probably not too hard to implement by mostly reusing existing code...

For some more discussion on the idea of Forgejo having a forum or similar discussion space see also forgejo/meta#116 (now archived).

My second thought is to engage with institutions, such as research institutes and large software foundations (e.g. Linux, Gnome, Apache), and encourage them to operate their own instances of Forgejo. At first, they might seek simply to provide alternatives sites for independent projects that might otherwise be hosted on Github, but eventually they also might migrate their own projects into the site.

This is an excellent example of the type of thing where we could use help from people with "soft skills" (communication etc) willing to volunteer their time to help the project.

> a fully featured web forum Slightly off topic, but in the long run I would love it if forgejo/forgejo#410 covered this use case... this is really something that in my opinion should be integrated into Forgejo as something that a lot of projects need. Technically it's mostly a case of repurposing issues and so (famous last words) is probably not _too_ hard to implement by mostly reusing existing code... For some more discussion on the idea of Forgejo having a forum or similar discussion space see also forgejo/meta#116 (now archived). > My second thought is to engage with institutions, such as research institutes and large software foundations (e.g. Linux, Gnome, Apache), and encourage them to operate their own instances of Forgejo. At first, they might seek simply to provide alternatives sites for independent projects that might otherwise be hosted on Github, but eventually they also might migrate their own projects into the site. This is an excellent example of the type of thing where we could use help from people with "soft skills" (communication etc) willing to volunteer their time to help the project.

KaKi87 commented 2023年08月26日 18:59:32 +02:00

Something that's just mostly human labor and cannot be made a lot more efficient is to get an reproducer, this really depends on the user reporting to explain what's going on.

I'd also volunteer to this, when it's not to hard to do.

A full forum seems to be needed instead or in addition, with support not only for discussions by topic, but also categories and announcements.

I disagree : labels work as categories and the blog works for announcements.

> Something that's just mostly human labor and cannot be made a lot more efficient is to get an reproducer, this really depends on the user reporting to explain what's going on. I'd also volunteer to this, when it's not to hard to do. > A full forum seems to be needed instead or in addition, with support not only for discussions by topic, but also categories and announcements. I disagree : labels work as categories and the blog works for announcements.

brainchild commented 2023年08月26日 22:59:42 +02:00

Slightly off topic, but in the long run I would love it if forgejo/forgejo#410 covered this use case... this is really something that in my opinion should be integrated into Forgejo as something that a lot of projects need.

Projects might benefit from a discussions feature in the forge, but such a feature would not replace a true integrated into application, hosted separately, for building community and broader interest.

This is an excellent example of the type of thing where we could use help from people with "soft skills" (communication etc) willing to volunteer their time to help the project.

A forum, with an announcements section, and a set of top-level discussion categories, independent from the development platform, would make it easier for such people to engage the project and to understand the needs.

I disagree : labels work as categories and the blog works for announcements.

There may be conceptual similarities, but labels are not substitute for a proper forum..

> Slightly off topic, but in the long run I would love it if forgejo/forgejo#410 covered this use case... this is really something that in my opinion should be integrated into Forgejo as something that a lot of projects need. Projects might benefit from a discussions feature in the forge, but such a feature would not replace a true integrated into application, hosted separately, for building community and broader interest. > This is an excellent example of the type of thing where we could use help from people with "soft skills" (communication etc) willing to volunteer their time to help the project. A forum, with an announcements section, and a set of top-level discussion categories, independent from the development platform, would make it easier for such people to engage the project and to understand the needs. > I disagree : labels work as categories and the blog works for announcements. There may be conceptual similarities, but labels are not substitute for a proper forum..

oliverpool commented 2023年09月15日 10:45:07 +02:00

I just read this post regarding bounties and the zig open source project, which I found quite interesting and could be relevant to this discussion:

https://ziglang.org/news/bounties-damage-open-source-projects/

I just read this post regarding bounties and the zig open source project, which I found quite interesting and could be relevant to this discussion: https://ziglang.org/news/bounties-damage-open-source-projects/

KaKi87 commented 2023年09月15日 14:22:49 +02:00

https://ziglang.org/news/bounties-damage-open-source-projects/

None of those instead-s offer a concrete alternative, though.

> https://ziglang.org/news/bounties-damage-open-source-projects/ None of those *instead*-s offer a concrete alternative, though.

danielopitz commented 2023年09月22日 23:50:05 +02:00

I'd be happy to help with programming, but I just have no idea where to start. I'm rather new to Go, but have enough programming know-how to get by. It is a rather large project and it would be great to have some guidance. Some documentation for new developers with the most basic stuff should be enough for starters (perhaps there is one and it's just not easy to find?).

• Should I contribute upstream (Gitea) or Forgejo?
• Can I set up a development environment quickly?
  • Can I do this without Docker?
• What should be tested? How should it be tested?
• How do I pick a task to work on?
  • Can someone help me with this? (I don't know the codebase yet and can't assess the difficulty)

Way too many open questions are quite a burden on the motivation. I'm not a super crazy extreme hacker 2000 and can't wrap my head around the codebase in an instant. I work full-time and I can't invest 2-3 weeks to get to know it all. Still, I could contribute a few hours here and there.

I'd be happy to help with programming, but I just have no idea where to start. I'm rather new to Go, but have enough programming know-how to get by. It is a rather large project and it would be great to have some guidance. Some documentation for new developers with the *most basic* stuff should be enough for starters (perhaps there is one and it's just not easy to find?). - Should I contribute upstream (Gitea) or Forgejo? - Can I set up a development environment quickly? - Can I do this without Docker? - What should be tested? How should it be tested? - How do I pick a task to work on? - Can someone help me with this? (I don't know the codebase yet and can't assess the difficulty) Way too many open questions are quite a burden on the motivation. I'm not a super crazy extreme hacker 2000 and can't wrap my head around the codebase in an instant. I work full-time and I can't invest 2-3 weeks to get to know it all. Still, I could contribute a few hours here and there.

caesar commented 2023年09月23日 00:39:12 +02:00

Some documentation for new developers with the most basic stuff should be enough for starters (perhaps there is one and it's just not easy to find?).

The developer documentation is at https://forgejo.org/docs/next/developer/. I agree it needs to be more approachable for new contributors. Feedback like yours helps with that, but we also need good technical writers to help out there...

https://forgejo.org/docs/next/developer/from-source/ answers some of your questions ("Can I set up a development environment quickly? Can I do this without Docker?" -> yes and yes)

The new architecture overview page is the best place to start getting familiar with how the codebase works.

Any specific questions, just ask. The most active contributors hang out in the Forgejo Development Matrix room and are generally very approachable and happy to help, and delighted to see new contributors!

All of that said, I 100% agree with you: we definitely do need to do more to make onboarding easier.

> Some documentation for new developers with the most basic stuff should be enough for starters (perhaps there is one and it's just not easy to find?). The developer documentation is at https://forgejo.org/docs/next/developer/. I agree it needs to be more approachable for new contributors. Feedback like yours helps with that, but we also need good technical writers to help out there... https://forgejo.org/docs/next/developer/from-source/ answers some of your questions (_"Can I set up a development environment quickly? Can I do this without Docker?"_ -> yes and yes) The new [architecture overview page](https://forgejo.org/docs/next/developer/architecture/) is the best place to start getting familiar with how the codebase works. Any specific questions, just ask. The most active contributors hang out in the [Forgejo Development Matrix room](https://matrix.to/#/#forgejo-development:matrix.org) and are generally very approachable and happy to help, and delighted to see new contributors! All of that said, I 100% agree with you: we definitely do need to do more to make onboarding easier.

caesar commented 2023年09月23日 00:43:06 +02:00

Should I contribute upstream (Gitea) or Forgejo?

This is to a great extent a personal choice. Any change made to Gitea will be merged into Forgejo within a week. Most changes (especially bugfixes) made in Forgejo will end up being upstreamed to Gitea, so if you contribute that kind of thing upstream, you save some work doing that. But some people feel more comfortable here and don't like to contribute upstream directly, and that's fine too.

> Should I contribute upstream (Gitea) or Forgejo? This is to a great extent a personal choice. Any change made to Gitea will be merged into Forgejo within a week. _Most_ changes (especially bugfixes) made in Forgejo will end up being upstreamed to Gitea, so if you contribute that kind of thing upstream, you save some work doing that. But some people feel more comfortable here and don't like to contribute upstream directly, and that's fine too.

danielopitz commented 2023年09月23日 00:51:29 +02:00

Thank you for the write up. I'll look into it and search for some approachable issues. As for the documentation: If I find things unclear or insufficient, I could at least create some issues in the docs project.

One more thing: It would be helpful to have a label for easy beginner issues ("great first issue" or something similar).

Thank you for the write up. I'll look into it and search for some approachable issues. As for the documentation: If I find things unclear or insufficient, I could at least create some issues in the docs project. One more thing: It would be helpful to have a label for easy beginner issues ("great first issue" or something similar).

caesar commented 2023年09月23日 00:55:32 +02:00

If I find things unclear or insufficient, I could at least create some issues in the docs project.

That would be great!

It would be helpful to have a label for easy beginner issues ("great first issue" or something similar).

I agree. One other thought, it can also be worthwhile checking the issues on the upstream Gitea repo, as most of them are equally applicable to Forgejo.

> If I find things unclear or insufficient, I could at least create some issues in the docs project. That would be great! > It would be helpful to have a label for easy beginner issues ("great first issue" or something similar). I agree. One other thought, it can also be worthwhile checking the issues on the upstream Gitea repo, as most of them are equally applicable to Forgejo.

danielopitz commented 2023年09月23日 01:09:41 +02:00

Sure, sounds good to me. I could help with the web dev / JS part of the website / Forgejo as well, that's my bread and butter.

Sure, sounds good to me. I could help with the web dev / JS part of the website / Forgejo as well, that's my bread and butter.

brainchild commented 2023年09月23日 06:05:51 +02:00

As a brief background, I have been learning, very slowly, about the Fediverse.

I have learned that some of the development, for Lemmy as the particular example, is funded by an European Commission initiative called Next Generation Internet (NGI).

As explained...

The Next Generation Internet (NGI) is a European Commission initiative that aims to shape the development and evolution of the Internet into an Internet of Trust. An Internet that responds to people’s fundamental needs, including trust, security, and inclusion, while reflecting the values and the norms all citizens enjoy in Europe.

One comment on social media explained that the organization has funded two developers for contributions to Lemmy.

It would be interesting if someone familiar with the broader issues, especially legal and labor practices in the EU, might offer thoughts on whether the organization might be a reasonable source from which to seek a grant.

As a brief background, I have been learning, very slowly, about the Fediverse. I have learned that some of the development, for Lemmy as the particular example, is funded by an European Commission initiative called [Next Generation Internet](https://www.ngi.eu/about/) (NGI). As explained... > The Next Generation Internet (NGI) is a European Commission initiative that aims to shape the development and evolution of the Internet into an Internet of Trust. An Internet that responds to people’s fundamental needs, including trust, security, and inclusion, while reflecting the values and the norms all citizens enjoy in Europe. One comment on social media explained that the organization has funded two developers for contributions to Lemmy. It would be interesting if someone familiar with the broader issues, especially legal and labor practices in the EU, might offer thoughts on whether the organization might be a reasonable source from which to seek a grant.

earl-warren commented 2023年09月23日 06:50:58 +02:00

I have learned that some of the development, for Lemmy as the particular example, is funded by an European Commission initiative called Next Generation Internet (NGI).

This is very relevant and a good source for funding 👍 Forgejo applied last December and was accepted in June this year (the delay was not because of the funding organization). As of this month it completed 40% of the workplan.

> I have learned that some of the development, for Lemmy as the particular example, is funded by an European Commission initiative called Next Generation Internet (NGI). This is very relevant and a good source for funding 👍 Forgejo applied [last December](https://codeberg.org/forgejo/sustainability/issues/1) and was accepted in June this year (the delay was not because of the funding organization). As of this month it completed [40% of the workplan](https://forgejo.org/2023-09-monthly-update/#sustainability).

brainchild commented 2023年09月23日 06:53:50 +02:00

Based on the comments preceding mine, I had understood that Forgejo is currently unfunded.

It seems I am misunderstanding the purpose and context of the discussion.

Based on the comments preceding mine, I had understood that Forgejo is currently unfunded. It seems I am misunderstanding the purpose and context of the discussion.

earl-warren commented 2023年09月23日 07:09:35 +02:00

My gut feeling is that current work on Forgejo is at least 75% done by volunteers and 25% by paid staff. It could be 50% / 50%, very difficult to say for sure, but my point is that it is not a project 100% volunteer based or the other way around. It is a mix.

This discussion is about increasing this workforce to absorb the workload. Either by appealing to volunteers. Or by finding additional sources of funding. Or... new ideas?

My gut feeling is that current work on Forgejo is at least 75% done by volunteers and 25% by paid staff. It could be 50% / 50%, very difficult to say for sure, but my point is that it is not a project 100% volunteer based or the other way around. It is a mix. This discussion is about increasing this workforce to absorb the workload. Either by appealing to volunteers. Or by finding additional sources of funding. Or... new ideas?

brainchild commented 2023年09月23日 07:41:53 +02:00

In earlier comments, I presented the idea that Forgejo as an organization might try to position itself for the software gaining recognition as an eventual member of the Fediverse, having the relation to Github and Gitlab analogous as Lemmy to Reddit, Mastadon to Twitter/X, and so on.

I am now perhaps grasping at straws in suggesting, considering the organization's strategic interests, that pathways for further funding might be opened through a proposal for support in integration with ActivityPub.

In earlier comments, I presented the idea that Forgejo as an organization might try to position itself for the software gaining recognition as an eventual member of the Fediverse, having the relation to Github and Gitlab analogous as Lemmy to Reddit, Mastadon to Twitter/X, and so on. I am now perhaps grasping at straws in suggesting, considering the organization's strategic interests, that pathways for further funding might be opened through a proposal for support in integration with ActivityPub.

earl-warren commented 2023年09月23日 08:02:39 +02:00

Federation is one area where there is activity & funding currently but it needs more. There are zillions of details to deal with and it could easily keep ten people full time busy and not stepping on each other toes. But this is true of other areas in Forgejo as well, not specific to Federation / ActivityPub / data portability.

Federation is one area where there is activity & funding currently but it needs more. There are zillions of details to deal with and it could easily keep ten people full time busy and not stepping on each other toes. But this is true of other areas in Forgejo as well, not specific to Federation / ActivityPub / data portability.

brainchild commented 2023年09月23日 08:06:49 +02:00

I understand.

The general strategy I was considering is of trying to resolve the areas that interest funders, and then telling them that those areas are specifically the ones that the project has been wanting to pursue.

I understand. The general strategy I was considering is of trying to resolve the areas that interest funders, and then telling them that those areas are specifically the ones that the project has been wanting to pursue.

caesar commented 2023年09月25日 13:35:10 +02:00

Here's quite a nice example of a project requesting contributions of various kinds, beyond just coding: https://graphite.rs/volunteer/

Here's quite a nice example of a project requesting contributions of various kinds, beyond just coding: https://graphite.rs/volunteer/

oliverpool commented 2024年01月25日 22:08:52 +01:00

Since I shared earlier about Zig criticizing bounties, I also have to share there new way:
https://ziglang.org/news/announcing-donor-bounties/

As I understand it:

• someone wants a feature
• they discuss with the project to agree on the scope and relevance of the feature, as well as the amount
• when the feature is implemented, the foundation (that would be Codeberg) gets the money

Individuals can still get some money, but it will have to go through Codeberg, who should be a sufficient hurdle to prevent the damage done by usual bounties.

Since I shared earlier about Zig criticizing bounties, I also have to share there new way: https://ziglang.org/news/announcing-donor-bounties/ As I understand it: - someone wants a feature - they discuss with the project to agree on the scope and relevance of the feature, as well as the amount - when the feature is implemented, the foundation (that would be Codeberg) gets the money Individuals can still get some money, but it will have to go through Codeberg, who should be a sufficient hurdle to prevent the damage done by usual bounties.