Decide how teams and projects are set up #4

hook commented 2025年05月20日 23:12:58 +02:00

As interest seems to be quite disperesed, it seems logical that we would need to separate the work and communication by skills/interests as well as events.

To kick off the discussion, I suggest we separate:

• teams: by what people want to contribute – e.g. webpage, hands-on organisation, code (if any), communication and moderation, etc.
• projects: each event would get its own project – e.g. WHY 2025, FOSDEM 2026, etc.

Better suggestions, very much welcome, of course.

As interest seems to be quite disperesed, it seems logical that we would need to separate the work and communication by skills/interests as well as events. To kick off the discussion, I suggest we separate: - teams: by what people want to contribute – e.g. webpage, hands-on organisation, code (if any), communication and moderation, etc. - projects: each event would get its own project – e.g. WHY 2025, FOSDEM 2026, etc. Better suggestions, very much welcome, of course.

LEdoian commented 2025年11月05日 00:54:28 +01:00

A project per event sounds good to me, though I am a bit worried about rights to the board:

• Who is able to move the "tickets" (group/group proposals) on the board?
• Given that the top post of the issue should probably contain most of the information: Who is able to change it?

Example pathological case: Alice (a stranger who found us by whatever way) wants to create join a train from Paramaribo (w.l.o.g), but cannot vouch to organise it (coordinate with the train company etc.), so she creates a ticket in the "looking for organisers" part of the board. Eventually, Bob (another stranger, maybe her friend) volunteers to organise that group, but he has no right to edit the top post of the Alice's issue.

In that case, the right way is probably to scrap Alice's ticket (close it and remove from board) and replace it with Bob's ticket in the "group exists" column, so that he has the right to add information to it. (Or, Bob could become part of the HackerTrain org in some less-privileged Team maybe?) This is not very intuitive. (And it may happen that Bob cedes the group organisation to Cody for some reason and there would be another round of issue deprecation?)

We'll test this in a few days in my test repo and hope to find a way to make this intuitive. (Also, something like this might be an issue with most available platforms really?)

A project per event sounds good to me, though I am a bit worried about rights to the board: - Who is able to move the "tickets" (group/group proposals) on the board? - Given that the top post of the issue should probably contain most of the information: Who is able to change it? Example pathological case: Alice (a stranger who found us by whatever way) wants to create join a train from Paramaribo (w.l.o.g), but cannot vouch to organise it (coordinate with the train company etc.), so she creates a ticket in the "looking for organisers" part of the board. Eventually, Bob (another stranger, maybe her friend) volunteers to organise that group, but he has no right to edit the top post of the Alice's issue. In that case, the right way is probably to scrap Alice's ticket (close it and remove from board) and replace it with Bob's ticket in the "group exists" column, so that he has the right to add information to it. (Or, Bob could become part of the HackerTrain org in some less-privileged Team maybe?) This is not very intuitive. (And it may happen that Bob cedes the group organisation to Cody for some reason and there would be another round of issue deprecation?) We'll test this in a few days in my test repo and hope to find a way to make this intuitive. (Also, something like this might be an issue with most available platforms really?)

LEdoian commented 2025年11月05日 00:56:54 +01:00

Also to note here: I am experimenting with a mockup board ("Project") for this: https://codeberg.org/LEdoian/test/projects/28931, so far it looks reasonable (I like it being reasonably usable and straightforward, yet not requiring too much infrastructure on our end and no separate registration.

Also to note here: I am experimenting with a mockup board ("Project") for this: <https://codeberg.org/LEdoian/test/projects/28931>, so far it looks reasonable (I like it being reasonably usable and straightforward, yet not requiring too much infrastructure on our end and no separate registration.

LEdoian commented 2025年11月05日 01:20:06 +01:00

Also, I guess for the event-projects a separate repo would be a good idea? So that we split the group and event organisation from the general initiative stuff (hopefully clear what I mean, words are a bit hard now, sorry :-))

Also, I guess for the event-projects a separate repo would be a good idea? So that we split the group and event organisation from the general initiative stuff (hopefully clear what I mean, words are a bit hard now, sorry :-))

LEdoian commented 2025年11月05日 18:40:37 +01:00

we'll test this in a few days

Well, that did not go too well. Forgejo projects aren't very programmable, so for people outside of the project it is only possible to add an issue into the default column. (I do like the "issues" part of it, though, having the option to have labels, templates and subscriptions.)

Relevant issues: #9384, #412, #6733, #5330, #6781.

> we'll test this in a few days Well, that did not go too well. Forgejo projects aren't very programmable, so for people outside of the project it is only possible to add an issue into the default column. (I do like the "issues" part of it, though, having the option to have labels, templates and subscriptions.) Relevant issues: [#9384](https://codeberg.org/forgejo/forgejo/pulls/9384), [#412](https://codeberg.org/forgejo/forgejo/issues/412), [#6733](https://codeberg.org/forgejo/forgejo/issues/6733), [#5330](https://codeberg.org/forgejo/forgejo/issues/5330), [#6781](https://codeberg.org/forgejo/forgejo/issues/6781).

hook commented 2026年01月05日 16:42:07 +01:00

Closing as this is now actually deployed and used :)

Closing as this is now actually deployed and used :)