Hi! There was a release party for this release. It was announced on Mastodon and the blog post only.
I'll just attach the results to this issue as an archive.
wild collaborative drawing created during the meeting
fnetx: sustainability and financing:
- we have (some) money - how we can we extend the capacity of Forgejo's development?
- anyone interested in doing paid work?
- any ideas on how to improve the handling?
fnetx: feedback about issue workflow - I know it's not the one I presented, but any problems in the current model would still be useful to know
- when filing technical problems (e.g. a regression), the form is getting annoying, a blank issue would be more convenient
Mathieu: code.forgejo.org -- should we run bleeding edge Forgejo there? #457
- potential security problems if it is compromised? → since there is no audit, there is no additional security in released versions. Merged code must be considered secure.
- → no objections, generally in favour
- → Forgejo Devops team needs to agree to handle the additional load that this could generate
- → Check that OAuth2 login uses the "new" scopes feature.
Mathieu: How do we manage PRs and feature proposals that increase the scope of Forgejo's capabilities? For example, Snippets/Gists, Package Cache, etc. These seem uniquely different than features that improve or refine current capabilities, and they seem to sit in a no-man's land where they don't get resolved
- list of requirements / decision process?
- requiring at least an amount of contributors to promise to take care of it in the long run?
- maybe "sponsoring" (not financially) where it requires at least x mergers to be supportive
- how relevant are these to users? Does standalone software exist already? Could it be standalone rather than integrated?
- bad to have features without love (e.g. projects/kanban boards) that are never improved after implementation and are not really working great
- fear of saying no
- Easy to say yes, but in the limbo state when the request is likely not going to be accepted.
- path forward could be to propose a policy / agreement via the decision-making process
- or even use individual decision processes per large feature
- plugins would be nice, but technically hard to do with golang (convenience, security, performance overhead)
- the approach that Caddy took could be interesting https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/107#issuecomment-84291
- merging code, but declaring it experimental: #246
- getting some features right for all user profiles is challenging
- self-hosted (easy to administer, install, resource efficient), public instances (scales, abuse resistant, robust to errors). Enterprise (Security compliance, auditable, configuration)
- for example pull-through cache: consider quota to prevent the cache from filling a public instance, avoid cache confusion attacks etc etc
- "sponsoring" with time commitment: as above, but the support signals need to come in soon; regular meetings among interested people
- alternatives that can be proposed to people on a "no":
- maintain a fork with that feature
- plugins? (we don't really have this, but, perhaps we could add a Caddy-based option)
- can this be an "integration" with an external piece of software, rather than a new feature in Forgejo
- experimental features
- even some existing features (Forgejo Actions) could have been external instead of being deeply integrated
→ fnetx: kinda related: working on large features (without being blocked, still doing it right)
- examples: moderation UI, quota feature
- potential problem: feedback loop too slow
Hi! There was a release party for this release. It was announced on Mastodon and the blog post only.
I'll just attach the results to this issue as an archive.
---
fnetx: sustainability and financing:
- we have (some) money - how we can we extend the capacity of Forgejo's development?
- anyone interested in doing paid work?
- any ideas on how to improve the handling?
fnetx: feedback about issue workflow - I know it's not the one I presented, but any problems in the current model would still be useful to know
- when filing technical problems (e.g. a regression), the form is getting annoying, a blank issue would be more convenient
Mathieu: code.forgejo.org -- should we run bleeding edge Forgejo there? https://codeberg.org/forgejo/discussions/issues/457
- potential security problems if it is compromised? → since there is no audit, there is no additional security in released versions. Merged code must be considered secure.
- → no objections, generally in favour
- → Forgejo Devops team needs to agree to handle the additional load that this could generate
- → Check that OAuth2 login uses the "new" scopes feature.
Mathieu: How do we manage PRs and feature proposals that increase the *scope* of Forgejo's capabilities? For example, Snippets/Gists, Package Cache, etc. These seem uniquely different than features that improve or refine current capabilities, and they seem to sit in a no-man's land where they don't get resolved
- list of requirements / decision process?
- requiring at least an amount of contributors to promise to take care of it in the long run?
- maybe "sponsoring" (not financially) where it requires at least x mergers to be supportive
- how relevant are these to users? Does standalone software exist already? Could it be standalone rather than integrated?
- bad to have features without love (e.g. projects/kanban boards) that are never improved after implementation and are not really working great
- fear of saying no
- Easy to say yes, but in the limbo state when the request is likely not going to be accepted.
- path forward could be to propose a policy / agreement via the decision-making process
- or even use individual decision processes per large feature
- plugins would be nice, but technically hard to do with golang (convenience, security, performance overhead)
- the approach that Caddy took could be interesting https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/107#issuecomment-84291
- merging code, but declaring it experimental: https://codeberg.org/forgejo/discussions/issues/246
- getting some features right for all user profiles is challenging
- self-hosted (easy to administer, install, resource efficient), public instances (scales, abuse resistant, robust to errors). Enterprise (Security compliance, auditable, configuration)
- for example pull-through cache: consider quota to prevent the cache from filling a public instance, avoid cache confusion attacks etc etc
- "sponsoring" with time commitment: as above, but the support signals need to come in soon; regular meetings among interested people
- alternatives that can be proposed to people on a "no":
- maintain a fork with that feature
- plugins? (we don't really have this, but, perhaps we *could* add a Caddy-based option)
- can this be an "integration" with an external piece of software, rather than a new feature in Forgejo
- experimental features
- even some existing features (Forgejo Actions) could have been external instead of being deeply integrated
→ fnetx: kinda related: working on large features (without being blocked, still doing it right)
- examples: moderation UI, quota feature
- potential problem: feedback loop too slow