Proposal for an open event calendar for Codeberg + projects hosted on Codeberg #785

Open
opened 3 weeks ago by lhinderberger · 41 comments

During the end of this weekend's Hackathon, the idea was thrown around to host a public, shared calendar for Codeberg and projects hosted on Codeberg.

There, projects could publish events (from large-scale, such as the Hackathon to small-scale, such as a regular get-together or an open planning/hacking session) and announce them to the entire Codeberg community + friends.

People could subscribe to that calendar e.g. via RSS or ActivityPub, and Codeberg could highlight certain events on their public channels.

This might lower the barrier for newcomers to contribute to Codeberg and other projects, and it might help smaller projects find contributors.

Possible technical solutions include:

Mobilizon and Gancio both come with a large feature-set included (e.g. ActivityPub support out-of-the-box).

Open questions include:

What are your thoughts on this? :-)

During the end of this weekend's Hackathon, the idea was thrown around to host a public, shared calendar for Codeberg and projects hosted on Codeberg. There, projects could publish events (from large-scale, such as the Hackathon to small-scale, such as a regular get-together or an open planning/hacking session) and announce them to the entire Codeberg community + friends. People could subscribe to that calendar e.g. via RSS or ActivityPub, and Codeberg could highlight certain events on their public channels. This might lower the barrier for newcomers to contribute to Codeberg and other projects, and it might help smaller projects find contributors. Possible technical solutions include: - Mobilizon (https://mobilizon.org) - Gancio (https://gancio.org/) - Other solutions that I haven't found yet 😉 - Writing our own open event calendar Mobilizon and Gancio both come with a large feature-set included (e.g. ActivityPub support out-of-the-box). Open questions include: - Do we want to host an open calendar? - How to authenticate users? It would be nice if you could log into the calendar with your Codeberg user account. (I don't know if it helps, but Mobilizon supports LDAP and OpenID Connect https://docs.joinmobilizon.org/administration/configure/auth/) What are your thoughts on this? :-)

https://github.com/coderbyheart/open-source-meetup-alternatives

Certain solutions support both .ICS (for shared calendars) and RSS (for hooking it up to the matrix room), such as Friendica and Mobilizon.

Federation in Mobilizon is still not working correctly for attendance as far as I can tell, at least not between Friendica vs. Mobilizon.

https://github.com/coderbyheart/open-source-meetup-alternatives Certain solutions support both .ICS (for shared calendars) and RSS (for hooking it up to the matrix room), such as Friendica and Mobilizon. Federation in Mobilizon is still not working correctly for attendance as far as I can tell, at least not between Friendica vs. Mobilizon.
rwa added the
service
label 3 weeks ago
Collaborator

Do we want to host an open calendar?

What's the exact defintion of an "open calendar", I presume everyone would be able to view the calendar, but only Codeberg core members be able to add events.

How to authenticate users? It would be nice if you could log into the calendar with your Codeberg user account. (I don't know if it helps, but Mobilizon supports LDAP and OpenID Connect

Gitea can act as a OAuth2 provider, it's an approach also taken by @bubu for https://translate.codeberg.org/

> Do we want to host an open calendar? What's the exact defintion of an "open calendar", I presume everyone would be able to view the calendar, but only Codeberg core members be able to add events. > How to authenticate users? It would be nice if you could log into the calendar with your Codeberg user account. (I don't know if it helps, but Mobilizon supports LDAP and OpenID Connect Gitea can [act as a OAuth2 provider](https://docs.gitea.io/en-us/oauth2-provider/), it's an approach also taken by @bubu for https://translate.codeberg.org/
Collaborator

What's the exact defintion of an "open calendar", I presume everyone would be able to view the calendar, but only Codeberg core members be able to add events.

I understood the initial proposal as such that everyone can add events for their own projects. (which is a concept I really like)

Mobilizon was started as a project to replace meetup.com and facebook events (IIRC), I think I participated in the crowdfuding of it quite a while back, but so far I've never really taken a loot at it.

If it is anything like I'd imagine it to be, this would hopefully be a good fit. Have a selection of losely related events (foss-software developed on codeberg) by different organizers all shown in some web-interface or shared via activitypub (and I'd hope rss and a subscribable calendar are also avaiable).

Definitely needs evaluation if this would be a good fit.

> What's the exact defintion of an "open calendar", I presume everyone would be able to view the calendar, but only Codeberg core members be able to add events. I understood the initial proposal as such that everyone can add events for their own projects. (which is a concept I really like) Mobilizon was started as a project to replace meetup.com and facebook events (IIRC), I think I participated in the crowdfuding of it quite a while back, but so far I've never really taken a loot at it. If it is anything like I'd imagine it to be, this would hopefully be a good fit. Have a selection of losely related events (foss-software developed on codeberg) by different organizers all shown in some web-interface or shared via activitypub (and I'd hope rss and a subscribable calendar are also avaiable). Definitely needs evaluation if this would be a good fit.
Collaborator

I understood the initial proposal as such that everyone can add events for their own projects. (which is a concept I really like)

Other than a concern for abuse, this indeed is cool. Another service for Codeberg to self-host 😅.

> I understood the initial proposal as such that everyone can add events for their own projects. (which is a concept I really like) Other than a concern for abuse, this indeed is cool. Another service for Codeberg to self-host 😅.

It would be an option to have separate calendars:

  • One open to events created by the community
  • One for Codeberg "boosting" curated events of the community (i.e., those that are deemed to be non-spam and beneficial to Codeberg/gitea in some way)
  • One for official Codeberg events

Then members are free to subscribe to whichever they want.

It would be an option to have separate calendars: * One open to events created by the community * One for Codeberg "boosting" curated events of the community (i.e., those that are deemed to be non-spam and beneficial to Codeberg/gitea in some way) * One for official Codeberg events Then members are free to subscribe to whichever they want.
lhinderberger closed this issue 3 weeks ago
lhinderberger reopened this issue 3 weeks ago

What's the exact defintion of an "open calendar", I presume everyone would be able to view the calendar, but only Codeberg core members be able to add events.

I understood the initial proposal as such that everyone can add events for their own projects. (which is a concept I really like)

Yep, that's how it was intended :-)

It would be an option to have separate calendars

That would be great. I don't know how if and how that can be realized though. One simple option would be to have a single (moderated) calendar for all, but to feature specific events publicly on dedicated channels (e.g. one automatic "All Events" stream and one human-curated "Featured Events" stream).

> > What's the exact defintion of an "open calendar", I presume everyone would be able to view the calendar, but only Codeberg core members be able to add events. > > I understood the initial proposal as such that everyone can add events for their own projects. (which is a concept I really like) Yep, that's how it was intended :-) > It would be an option to have separate calendars That would be great. I don't know how if and how that can be realized though. One simple option would be to have a single (moderated) calendar for all, but to feature specific events publicly on dedicated channels (e.g. one automatic "All Events" stream and one human-curated "Featured Events" stream).
Owner

I'm looking forward to trying Mobilizon. The second option sounds also interesting, we could compare the two.

Just dropping here since I just saw it elsewhere: https://codeberg.org/Community-Square/calendar/raw/branch/ics/calendar.ics (managing a calendar file in Git, would allow easy PRing, there are web calendar viewers as Free Software available AFAIK).


I'd pretty much start this as semi-moderated experiment. Allow everyone to announce an event. If we see too much spam, we could moderate a little more.

Or we allow all Codeberg e.V. members to publish events and people can request listing of their events.

I'm looking forward to trying Mobilizon. The second option sounds also interesting, we could compare the two. Just dropping here since I just saw it elsewhere: https://codeberg.org/Community-Square/calendar/raw/branch/ics/calendar.ics (managing a calendar file in Git, would allow easy PRing, there are web calendar viewers as Free Software available AFAIK). --- I'd pretty much start this as semi-moderated experiment. Allow everyone to announce an event. If we see too much spam, we could moderate a little more. Or we allow all Codeberg e.V. members to publish events and people can request listing of their events.

git & PR sounds like an interesting solution. You could even hook up the RSS feed of the git repo to the matrix room via the built-in RSS bot.

git & PR sounds like an interesting solution. You could even hook up the RSS feed of the git repo to the matrix room via the built-in RSS bot.

The git & web viewer & RSS/Matrix/Mastodon-bot solution sounds like a quick and easy solution to get this started, I like it!

Regarding web viewers, https://github.com/niccokunzmann/open-web-calendar seems what we're looking for. There's an instance running at Heroku (https://openwebcalendar.herokuapp.com/) but it looks like the underlying software is GPLv2-licensed and self-hostable.

The git & web viewer & RSS/Matrix/Mastodon-bot solution sounds like a quick and easy solution to get this started, I like it! Regarding web viewers, https://github.com/niccokunzmann/open-web-calendar seems what we're looking for. There's an instance running at Heroku (https://openwebcalendar.herokuapp.com/) but it looks like the underlying software is GPLv2-licensed and self-hostable.

Although, on second thought, I personally would prefer a JavaScript-only solution for the web viewer, since then we could host the entire thing without spinning up any additional server-side app (e.g. on Codeberg Pages).

EDIT: We might need to allow Cross-Origin access to the ICS files though for that, depending on how it's currently set up.

Although, on second thought, I personally would prefer a JavaScript-only solution for the web viewer, since then we could host the entire thing without spinning up any additional server-side app (e.g. on Codeberg Pages). EDIT: We might need to allow Cross-Origin access to the ICS files though for that, depending on how it's currently set up.
Owner

Haha, I was also mainly thinking about the open web calendar from nicco ^^. But maybe there are better tools for integration with Codeberg ...

What about having a simple generator script to create the ics file from another (text, md, ini, yaml, toml, ...) file? This would ensure that PRs don't accidentally break the format and save people the effort to manually fiddle with the ics file?

Haha, I was also mainly thinking about the open web calendar from nicco ^^. But maybe there are better tools for integration with Codeberg ... What about having a simple generator script to create the ics file from another (text, md, ini, yaml, toml, ...) file? This would ensure that PRs don't accidentally break the format and save people the effort to manually fiddle with the ics file?

Maybe a CI pipeline that automatically converts a simpler input format to ICS + a statically rendered HTML calendar/"bulletin board", and that deploys it to Pages?

Maybe a CI pipeline that automatically converts a simpler input format to ICS + a statically rendered HTML calendar/"bulletin board", and that deploys it to Pages?

The format could look something like this:

events:
  foo-event:
    title: A Foo Event
    description: A one-time event where we talk about foo
    begin: 2022-11-08T16:30:00Z
    end: 2022-11-08T23:00:00Z
    meeting-link: https://...
    thumbnail: filename.png # would be copied to site generator output
    homepage: ...
    matrix-room: ...
  bar-meetup-123:
    title: A Bar Meetup #123
    description: John Doe gives a talk about deploying bar on your own server
    begin: 2022-11-09T19:30:00Z
    end: 2022-11-09T21:00:00Z
    meeting-link: https://...
    thumbnail: filename.png
    homepage: ...
    matrix-room: ...
featured: # to be shown at the top of the page, above a list of all events
  - foo-event
  - ...

We could later add support for "placeholders" for future recurring meetings, but in the beginning I think it would be fine to just maintain the meetings of the next couple of days/weeks manually.

The format could look something like this: ```yaml events: foo-event: title: A Foo Event description: A one-time event where we talk about foo begin: 2022-11-08T16:30:00Z end: 2022-11-08T23:00:00Z meeting-link: https://... thumbnail: filename.png # would be copied to site generator output homepage: ... matrix-room: ... bar-meetup-123: title: A Bar Meetup #123 description: John Doe gives a talk about deploying bar on your own server begin: 2022-11-09T19:30:00Z end: 2022-11-09T21:00:00Z meeting-link: https://... thumbnail: filename.png homepage: ... matrix-room: ... featured: # to be shown at the top of the page, above a list of all events - foo-event - ... ``` We could later add support for "placeholders" for future recurring meetings, but in the beginning I think it would be fine to just maintain the meetings of the next couple of days/weeks manually.
Owner

instead of splitting into events and featured (for a simpler file and less indentation), I'd use each event as first-level node and only introduce a featured: true, but otherwise LGTM.

instead of splitting into events and featured (for a simpler file and less indentation), I'd use each event as first-level node and only introduce a `featured: true`, but otherwise LGTM.

Alright, I'll go ahead and build a quick prototype then at https://codeberg.org/lhinderberger/calendity :-)

Alright, I'll go ahead and build a quick prototype then at https://codeberg.org/lhinderberger/calendity :-)
Owner

I can also create a repo at /Codeberg for you.

I can also create a repo at /Codeberg for you.

I can also create a repo at /Codeberg for you.

Thanks! I am planning to turn the prototype into a template project that others can use to build their own open calendar too. So it would be good to separate the generic-calendar-site-template and the Codeberg-specific part.

I will get back to you once the prototype is ready so that we can discuss if and how to integrate it with /Codeberg.

> I can also create a repo at /Codeberg for you. Thanks! I am planning to turn the prototype into a template project that others can use to build their own open calendar too. So it would be good to separate the generic-calendar-site-template and the Codeberg-specific part. I will get back to you once the prototype is ready so that we can discuss if and how to integrate it with /Codeberg.

I have played around with Eleventy a bit over the last few days and came up with a setup that generates an iCal calendar plus an RSS feed, alongside with a web site and nice details pages for a given set of events described as YAML + Markdown.

Instead of putting all events into one single large YAML file, which would quickly get crowded, I have put each event into its own file.

The setup's source code is available at https://codeberg.org/lhinderberger/calendity

To replicate it, you can either fork the repository or use the repo as a template (I have set it up as a template project in Gitea).

Now there's one big problem though: I wanted to setup the CI to automatically build the site and push the result to the pages branch once new commits arrive at the master branch. But then I saw in the Woodpecker documentation that Secrets are not safe if they are enabled for use in Pull Requests. The problem now is that such an "Open Events Repository" would be pointless if people couldn't make PRs to add events. Building the site manually after each merged PR would be easy to forget though. And while we probably need a cron job to update the page every once in a while (to get past events off the front page), it might be a nuisance to have to wait hour(s) before a new event arrives in the calendar. If we on the other hand configure the cron job to run often-ish (e.g. every 15mins) that would mean quite some wasted resources. Does someone who's more familiar with Woodpecker know a good way out of this dilemma?

I have played around with Eleventy a bit over the last few days and came up with a setup that generates an iCal calendar plus an RSS feed, alongside with a web site and nice details pages for a given set of events described as YAML + Markdown. Instead of putting all events into one single large YAML file, which would quickly get crowded, I have put each event into its own file. The setup's source code is available at https://codeberg.org/lhinderberger/calendity To replicate it, you can either fork the repository or use the repo as a template (I have set it up as a template project in Gitea). Now there's one **big** problem though: I wanted to setup the CI to automatically build the site and push the result to the pages branch once new commits arrive at the master branch. But then I saw in the Woodpecker documentation that Secrets are not safe if they are enabled for use in Pull Requests. The problem now is that such an "Open Events Repository" would be pointless if people couldn't make PRs to add events. Building the site manually after each merged PR would be easy to forget though. And while we probably need a cron job to update the page every once in a while (to get past events off the front page), it might be a nuisance to have to wait hour(s) before a new event arrives in the calendar. If we on the other hand configure the cron job to run often-ish (e.g. every 15mins) that would mean quite some wasted resources. Does someone who's more familiar with Woodpecker know a good way out of this dilemma?

I haven't looked at the code yet, but what you shared above sounds awesome!

Why do you want to enable secrets in PRs, though? Would you like to generate a pre-rendering for the PR reviewer? The PR hook should just run a syntax check and a little numerical sanity checking on the input file but nothing more.

You would only need to deploy after merging.

And also, if you spiced up the little generated web page with optional JavaScript, you could hide past events automatically and in real time and would only need to regenerate it rarely.

If you generated a compact annual calendar view that wouldn't need updating at all. But surely the web page is probably just the cherry on top - the iCal & RSS are the most important part.

However, I recommend that we also keep SEO in mind. For that, it is still valuable to be able to reach past events and if every path is a permalink.

I haven't looked at the code yet, but what you shared above sounds awesome! Why do you want to enable secrets in PRs, though? Would you like to generate a pre-rendering for the PR reviewer? The PR hook should just run a syntax check and a little numerical sanity checking on the input file but nothing more. You would only need to deploy after merging. And also, if you spiced up the little generated web page with optional JavaScript, you could hide past events automatically and in real time and would only need to regenerate it rarely. If you generated a compact annual calendar view that wouldn't need updating at all. But surely the web page is probably just the cherry on top - the iCal & RSS are the most important part. However, I recommend that we also keep SEO in mind. For that, it is still valuable to be able to reach past events and if every path is a permalink.
Owner

Regarding Woodpecker: I'd still love to see resource saving by using better schedules implemented. What about either combining cron (every day or less frequent) + per commit? (I am also a fan of requiring a button press from maintainers until a build fires).

Another idea, which might save installing the dependencies (but cannot skip the clone step): Cron job runs often and only checks with some shell script if the page needs updating (e.g. checks when the latest push happened, or if a calendar end date was yesterday (using grep, for example, skipping the build + dependencies if no update is necessary).

Regarding Woodpecker: I'd still love to see resource saving by using better schedules implemented. What about either combining cron (every day or less frequent) + per commit? (I am also a fan of requiring a button press from maintainers until a build fires). Another idea, which might save installing the dependencies (but cannot skip the clone step): Cron job runs often and only checks with some shell script if the page needs updating (e.g. checks when the latest push happened, or if a calendar end date was yesterday (using grep, for example, skipping the build + dependencies if no update is necessary).

I haven't looked at the code yet, but what you shared above sounds awesome!

Thanks, that's much appreciated :-)

Why do you want to enable secrets in PRs, though? Would you like to generate a pre-rendering for the PR reviewer? The PR hook should just run a syntax check and a little numerical sanity checking on the input file but nothing more.

Exactly, the CI would run on PRs basically for smoke testing. Then, when the PR is merged, a rebuild of the site would need to be triggered - I assumed that this is also part of the "Pull Request" event, but I might be wrong there. If I'm not wrong, couldn't a malicious actor create a PR that modifies the .woodpecker.yml to extract the secret in the verification step?

And also, if you spiced up the little generated web page with optional JavaScript, you could hide past events automatically and in real time and would only need to regenerate it rarely.

If you generated a compact annual calendar view that wouldn't need updating at all. But surely the web page is probably just the cherry on top - the iCal & RSS are the most important part.

Sounds both pretty cool, definitely worth considering for future improvements 👍

However, I recommend that we also keep SEO in mind. For that, it is still valuable to be able to reach past events and if every path is a permalink.

Agreed (and already works! 😃)

> I haven't looked at the code yet, but what you shared above sounds awesome! Thanks, that's much appreciated :-) > Why do you want to enable secrets in PRs, though? Would you like to generate a pre-rendering for the PR reviewer? The PR hook should just run a syntax check and a little numerical sanity checking on the input file but nothing more. Exactly, the CI would run on PRs basically for smoke testing. Then, when the PR is merged, a rebuild of the site would need to be triggered - I assumed that this is also part of the "Pull Request" event, but I might be wrong there. If I'm not wrong, couldn't a malicious actor create a PR that modifies the `.woodpecker.yml` to extract the secret in the verification step? > And also, if you spiced up the little generated web page with optional JavaScript, you could hide past events automatically and in real time and would only need to regenerate it rarely. > > If you generated a compact annual calendar view that wouldn't need updating at all. But surely the web page is probably just the cherry on top - the iCal & RSS are the most important part. Sounds both pretty cool, definitely worth considering for future improvements 👍 > However, I recommend that we also keep SEO in mind. For that, it is still valuable to be able to reach past events and if every path is a permalink. Agreed (and already works! 😃)

I'm not an authoritive source on this, so just guessing. You should probably leave it at the default of not providing the secrets for the PR. I think what you will want is that a deploy happens on push to master - that's when a maintainer clicks on the merge button.
https://woodpecker-ci.org/docs/usage/secrets#pull-requests

I recommend we think about how to render a preview for the PR reviewer as a future improvement. But basically in other CI systems, build steps can generate artifacts that one can view direrctly (e.g., HTML) and/or download as a zip within temporary folders within the CI system. No deployment and no secret is required in such cases.

I'm not an authoritive source on this, so just guessing. You should probably leave it at the default of not providing the secrets for the PR. I _think_ what you will want is that a deploy happens on push to master - that's when a maintainer clicks on the merge button. https://woodpecker-ci.org/docs/usage/secrets#pull-requests I recommend we think about how to render a preview for the PR reviewer as a future improvement. But basically in other CI systems, build steps can generate artifacts that one can view direrctly (e.g., HTML) and/or download as a zip within temporary folders within the CI system. No deployment and no secret is required in such cases.
https://woodpecker-ci.org/plugins/Surge%20preview%20plugin

I think what you will want is that a deploy happens on push to master - that's when a maintainer clicks on the merge button.

You're right, that would be the best solution. Maybe I'm just overthinking it (me being super tired doesn't help either 😄), and it will simply run the "push" CI on PR merge as well. I think its best if I get some sleep now, and then have a look at this tomorrow :-) Thank you for your help!

> I _think_ what you will want is that a deploy happens on push to master - that's when a maintainer clicks on the merge button. You're right, that would be the best solution. Maybe I'm just overthinking it (me being super tired doesn't help either 😄), and it will simply run the "push" CI on PR merge as well. I think its best if I get some sleep now, and then have a look at this tomorrow :-) Thank you for your help!

After much fighting with Murphy's Law, I managed to get a CI pipeline up-and-running that automatically deploys to Codeberg Pages.

This is the Pipeline definition: https://codeberg.org/lhinderberger/calendity-pages-test/src/branch/master/.woodpecker.yml

And this is the rendered result: https://lhinderberger.codeberg.page/calendity-pages-test/

I wasn't able to test if PRs work yet, due to issue #795

After much fighting with Murphy's Law, I managed to get a CI pipeline up-and-running that automatically deploys to Codeberg Pages. This is the Pipeline definition: https://codeberg.org/lhinderberger/calendity-pages-test/src/branch/master/.woodpecker.yml And this is the rendered result: https://lhinderberger.codeberg.page/calendity-pages-test/ I wasn't able to test if PRs work yet, due to issue #795

Looking at the Woodpecker CI logs, the CI seems to have worked fine verifying the PR, and it didn't deploy accidentally either 😉

Now all we need to find out is whether it behaves as expected when merging the PR in Gitea, which is blocked by #795.

Looking at the Woodpecker CI logs, the CI seems to have worked fine verifying the PR, and it didn't deploy accidentally either 😉 Now all we need to find out is whether it behaves as expected when merging the PR in Gitea, which is blocked by #795.

Syncing the RSS and iCal with Thunderbird works too (although the description of already received events in the RSS is not updated)! 🥳

Syncing the RSS and iCal with Thunderbird works too (although the description of already received events in the RSS is not updated)! 🥳

I was able to regain access to the Pull Request, and I'm very happy to report that Pull Requests also work as intended (and so do edits directly from within Gitea).

So, if we want to go ahead with this idea, we could create a Codeberg/Events repository that we fork from lhinderberger/calendity (or use the template project with the same name, at your preference - forking might make it easier to rebase/cherry-pick on further improvements though).

There, we could apply Codeberg-specific styling and replace the example events with some actual upcoming events.

CC @fnetX

I was able to regain access to the Pull Request, and I'm very happy to report that Pull Requests also work as intended (and so do edits directly from within Gitea). So, if we want to go ahead with this idea, we could create a Codeberg/Events repository that we fork from lhinderberger/calendity (or use the template project with the same name, at your preference - forking might make it easier to rebase/cherry-pick on further improvements though). There, we could apply Codeberg-specific styling and replace the example events with some actual upcoming events. CC @fnetX

Release v1.1.0 of calendity is now ready, adding (amongst other things) optional client-side JavaScript that auto-hides past events and fixing a bug in iCal production.

@fnetX - are we ready to move this forward to Codeberg/Events?

Release v1.1.0 of calendity is now ready, adding (amongst other things) optional client-side JavaScript that auto-hides past events and fixing a bug in iCal production. @fnetX - are we ready to move this forward to Codeberg/Events?
Owner

You should have all necessary permissions now.

You should have all necessary permissions now.

Thanks, I'll move over the CI configuration, drop the example events and adapt the README as soon as I find some time for it (and after fixing lhinderberger/calendity#9) :-)

We should also adapt the styling of the page to better fit Codeberg, but I can't find the Codeberg Design Toolkit any more. 🤔

Thanks, I'll move over the CI configuration, drop the example events and adapt the README as soon as I find some time for it (and after fixing https://codeberg.org/lhinderberger/calendity/issues/9) :-) We should also adapt the styling of the page to better fit Codeberg, but I can't find the Codeberg Design Toolkit any more. 🤔
Owner

The Design Toolkit is still available via https://design.codeberg.org. There is currently no real repo of origin, but it's served from https://codeberg.org/Codeberg-Infrastructure/static-deployments/src/branch/design#.

@vednoc is considering to rewrite this, as the current design kit isn't very efficient, and light/dark theme switching does not work without JS, and it has some other flaws IMHO. If you add a blue navbar, it might be fine already.

The Design Toolkit is still available via https://design.codeberg.org. There is currently no real repo of origin, but it's served from https://codeberg.org/Codeberg-Infrastructure/static-deployments/src/branch/design#. @vednoc is considering to rewrite this, as the current design kit isn't very efficient, and light/dark theme switching does not work without JS, and it has some other flaws IMHO. If you add a blue navbar, it might be fine already.

@fnetX Can you give me more permissions to the Codeberg/Events repo, so that I can generate a deployment key (and while I'm at it, also turn off Wiki/Projects/Packages for that particular repo)?

@fnetX Can you give me more permissions to the Codeberg/Events repo, so that I can generate a deployment key (and while I'm at it, also turn off Wiki/Projects/Packages for that particular repo)?

Oh, and a little heads-up: calendity has been relicensed to Apache 2.0, from MPLv2 previously.

Oh, and a little heads-up: calendity has been relicensed to Apache 2.0, from MPLv2 previously.
Owner

You're now a repo admin and should be able to adjust this yourself.

You're now a repo admin and should be able to adjust this yourself.

Perfect, thank you! :-)

Perfect, thank you! :-)

A first version is now available at https://codeberg.codeberg.page/Events/

I have decided not to use the design toolkit and to write a simple navbar instead, as you have suggested.

Next steps would be adding the first few events, setting up events.codeberg.org and adding a link to it to the site footer :-)

A first version is now available at https://codeberg.codeberg.page/Events/ I have decided not to use the design toolkit and to write a simple navbar instead, as you have suggested. Next steps would be adding the first few events, setting up events.codeberg.org and adding a link to it to the site footer :-)
Owner

Great. I think I'll share on socialmedia soon.

Great. I think I'll share on socialmedia soon.

Should we add at least one official event in the calendar before publishing, though?

... Or even just one elapsed official event.

Should we add at least one official event in the calendar before publishing, though? ... Or even just one elapsed official event.

Should we add at least one official event in the calendar before publishing, though?

Yes please! Let's not announce an empty calendar to the general public 😅

If the time is already known, we might for instance add the next Hackathon or the next Codeberg e.V. general assembly.

> Should we add at least one official event in the calendar before publishing, though? Yes please! Let's not announce an empty calendar to the general public 😅 If the time is already known, we might for instance add the next Hackathon or the next Codeberg e.V. general assembly.
Owner

Yes, that's why I didn't immediately shared. I would likely also announce the project in iterations, e.g. first in Matrix channel where community is usually following our progress more actively (they could add events), then to Mastodon once it's more interesting.

Yes, that's why I didn't immediately shared. I would likely also announce the project in iterations, e.g. first in Matrix channel where community is usually following our progress more actively (they could add events), then to Mastodon once it's more interesting.
Sign in to join this conversation.
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Codeberg/Community#785
Loading…
There is no content yet.