feat: simplify meetings scheduling #297

derberg · 2022-03-17T11:08:12Z

As part of work related to #245

I wanted to first refactor and simplify the way we actually create event-related issues as even though it was easy already, for me it was still not super easy, especially everytimezone links. I'm too lazy person 😞

I want to incrementally add changes to meetings scheduling, this will do few and not one killer PR.

What this PR changes:
Now to schedule a meeting you had one workflow to trigger, with a form with few fields:

Now every meeting has its own workflow, we no longer use everytimezone and it is much simplified to say when the meeting takes place:

Example issues created with new workflows are here: https://github.com/derberg/test-experiment/issues

Code in workflows got a bit simplified, especially for the purpose if we get more workflows and avoiding duplication as much as possible.

You can see that in this PR I merge in some code from other libraries. It is explained in the readme. But in next PRs it might changes, especially when I will start adding libraries that I will need for taking with Google, Zoom and Mailchimp APIs

Looking forward for feedback
☮️

@jonaslagoni pinging you as current user of the meeting workflow

jonaslagoni · 2022-03-17T11:13:01Z

I think we should adapt the workflow to be fully automatic tbh, I dont care much for inputs 😆

For example for spec 3.0, is there a reason why it is not automatically created Wednesday after 17 PM UTC (this can be defined in the workflow file as a recurring event)? And instead of inputs, it just finds the next available day based on the schedule (bi-weekly meeting) 🤔

That way no one needs permissions and issues are always up.

But yea, just a thought.

This means that to "start" a new meeting you just provide a PR with when you want it to happen and everything else works is automated until you remove that meeting in another PR.

fmvilas · 2022-03-17T11:18:48Z

.github/workflows/create-event-issue-community-meeting.yml

+            const setupMeeting = require('./.github/workflows/event_issue_templates/index.js');
+            setupMeeting('${{ github.event.inputs.date }}', '${{ github.event.inputs.time }}', core, getMeetingIssueContent);
+      - name: Create issue with meeting details
+        run: gh issue create -l meeting -t "Community Meeting, ${{steps.date.outputs.hour}} UTC ${{steps.date.outputs.fullDate}}" -F content.md


It looks weird because it results in the time being expressed as 08 or 16 instead of 08:00 or 16:00. Would be awesome to either format the date here or change the input descriptions above to suggest people use 08:00 format instead (I mean, they add :00).

Also, would it be possible to schedule a meeting at 08:15 for instance? Or is it only accepting numbers?

actually the result is 8 or 16, and yes, no :00 and no :15. The reason:

it is for issue title, for humans, and when humans talk, they do not say we meet at 08 but at 8

we can for sure add minutes support for the future, but last 2 years at the project I haven't see us doing it, so why add feature if we do not need it?

@fmvilas ping 😉

we can for sure add minutes support for the future, but last 2 years at the project I haven't see us doing it, so why add feature if we do not need it?

Sure, that's fine for now.

it is for issue title, for humans, and when humans talk, they do not say we meet at 08 but at 8

We're not talking, we're reading. It was confusing to me at first to see the number 8. My brain was confused for a few seconds wondering if that's the day or the time or what. Since we're not going to support minutes, I'd just add :00 after the number so it's easier to scan for the time at a glance.

@fmvilas but you do know it was like this always, I did not change anything? so how is it confusing now? 😄

@fmvilas it is not about weirdness. I'm just reluctant to change something that was always there (like about 2 years since we create these), used by many people, and literally zero feedback that it is confusing. And now you suggest improving it even though you admit you do not use it 😆

I don't have to use it to give you feedback, otherwise, I wouldn't be giving feedback on most of the AsyncAPI tools 😄 I think I'm giving you a reasonable explanation why I think it's better and all I receive from you is "it's always been like this".

Don't you think a format like hh:mm would help scanning the title faster? And I don't think it's that much of a deal. I'm not asking you to support minutes but to hardcode :00 after the hour number 🤷‍♂️

It's ok if you don't want to do it but please give me a better reason 🙏

What is wrong with "it's always been like this" statement? Why is it a bad reason? If it is backed by the statement that till now there was 0 negative feedback about it. Even though many people look into those, suggest adding agenda items, etc.

Don't you think a format like hh:mm would help scan the title faster?

Spec 3.0 Meeting, 16 UTC Wednesday March 30 2022
vs
Spec 3.0 Meeting, 16:00 UTC Wednesday March 30 2022

not really 😄 as I wrote, whey you "talk" or even write, you do not say we meet at 8:00, but you say/write 8, unless it is 8:30 🤷🏼 I can bet that in Slack when you write with someone, that you will meet with a person, you never say, let's meet at 4:00 but you will for sure write let's meet at 4 😄 I actually went through our private messages, and you add : only if we are about to meet at :15 or :30 or :45 but never :00.

Anyway, if ☝🏼 is not an argument for you, then I give up and can change to :00 👍🏼

I was about to answer the same. I don't really care much to continue arguing so up to you 👍

@fmvilas it was a good argue though 😄 I added :00. Please approve

derberg · 2022-03-17T11:42:46Z

I think we should adapt the workflow to be fully automatic tbh, I dont care much for inputs 😆
For example for spec 3.0, is there a reason why it is not automatically created Wednesday after 17 PM UTC (this can be defined in the workflow file as a recurring event)? And instead of inputs, it just finds the next available day based on the schedule (bi-weekly meeting) 🤔
That way no one needs permissions and issues are always up.
But yea, just a thought.
This means that to "start" a new meeting you just provide a PR with when you want it to happen and everything else works is automated until you remove that meeting in another PR.

@jonaslagoni not all meetings are regular, some are "ondemand", like the one for contributors, or Thinking Out Loud. Also, you still need permissions to update issue, to close issue (in future this will also have automation underneath, so when you close the issue before the meeting happened, it will be also canceled in the calendar and zoom).

jonaslagoni · 2022-03-17T11:48:39Z

@jonaslagoni not all meetings are regular, some are "ondemand", like the one for contributors, or Thinking Out Loud. Also, you still need permissions to update issue, to close issue (in future this will also have automation underneath, so when you close the issue before the meeting happened, it will be also canceled in the calendar and zoom).

Ahh okay, yes that makes sense, so what you are saying is that what is introduced here is needed regardless of whether we fully automate recuring meeting 🙂

derberg · 2022-03-17T12:07:23Z

Ahh okay, yes that makes sense, so what you are saying is that what is introduced here is needed regardless of whether we fully automate recuring meeting 🙂

more or less yes 😆
but yeah, the whole automation is based on the "issue" existence:

issue created - means schedule is performed
issue closed after meeting happened - nothing happens (maybe in future we can do some youtube automation, like add stream to relevant playlist......but this is stretch objective and we can ask community to add it)
issue is closed before meeting happened - meeting is removed from calendar and zoom

so in next PRs, also issue content will be evolving, probably some metadata will have to be added, maybe labels. I'm not 100% sure. I do it one by one, do not have time to work on it full-time-focus so I do not plan entire functionality in details

anyway, meeting as a service is a beast, lots of different APIs, complex shit that required lots of research. I need to provide on my own initial "framework" so later we can hand it over to first time contributors that can add bits and peaces here and there to remove more manual steps, one after another.

does it make sense?

@jonaslagoni but I do have you close to my ❤️ , look at related issue #245
in description you can find something like that:

Bonus:
many meetings have defined schedule, so would be nice to have an option to also schedule the meeting with automation only once, and then there would be a workflow that automatically creates GitHub issue for given meeting.

jonaslagoni · 2022-03-17T12:56:03Z

does it make sense?

Yep 👍

@jonaslagoni but I do have you close to my ❤️ , look at related issue #245 in description you can find something like that:

Ahh, missed that, perfect 👌

jonaslagoni

LGTM 👍

derberg · 2022-03-17T14:47:37Z

@jonaslagoni but we will have to continue discussion or "scheduled" meetings when I will start working on it. As even though community meeting is reoccurring, I personally prefer to schedule them manually, to have control. But yeah, will ping ya

derberg · 2022-03-23T11:43:34Z

/rtm

derberg added 5 commits March 16, 2022 18:32

feat: add meetings automation

5f036f6

add some logging

f3afca2

v

d0f97b2

add sufux

a1cf2aa

update meeting readme

88cf0d4

derberg requested review from fmvilas, quetzalliwrites and asyncapi-bot-eve as code owners March 17, 2022 11:08

fmvilas reviewed Mar 17, 2022

View reviewed changes

jonaslagoni previously approved these changes Mar 17, 2022

View reviewed changes

derberg requested a review from fmvilas March 17, 2022 17:08

add :00

384ff0e

derberg dismissed jonaslagoni’s stale review via 384ff0e March 23, 2022 11:08

Merge branch 'master' into meetingasaservice

88aae49

fmvilas approved these changes Mar 23, 2022

View reviewed changes

asyncapi-bot added the ready-to-merge label Mar 23, 2022

asyncapi-bot merged commit 6ecdff8 into asyncapi:master Mar 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: simplify meetings scheduling #297

feat: simplify meetings scheduling #297

derberg commented Mar 17, 2022

jonaslagoni commented Mar 17, 2022 •

edited

Loading

fmvilas Mar 17, 2022

derberg Mar 17, 2022

derberg Mar 21, 2022

fmvilas Mar 21, 2022

derberg Mar 21, 2022

derberg Mar 22, 2022 •

edited

Loading

fmvilas Mar 22, 2022 •

edited

Loading

derberg Mar 22, 2022

fmvilas Mar 22, 2022

derberg Mar 23, 2022

derberg commented Mar 17, 2022 •

edited

Loading

jonaslagoni commented Mar 17, 2022

derberg commented Mar 17, 2022

jonaslagoni commented Mar 17, 2022

jonaslagoni left a comment

derberg commented Mar 17, 2022

derberg commented Mar 23, 2022

feat: simplify meetings scheduling #297

feat: simplify meetings scheduling #297

Conversation

derberg commented Mar 17, 2022

jonaslagoni commented Mar 17, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

derberg Mar 22, 2022 • edited Loading

Choose a reason for hiding this comment

fmvilas Mar 22, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

derberg commented Mar 17, 2022 • edited Loading

jonaslagoni commented Mar 17, 2022

derberg commented Mar 17, 2022

jonaslagoni commented Mar 17, 2022

jonaslagoni left a comment

Choose a reason for hiding this comment

derberg commented Mar 17, 2022

derberg commented Mar 23, 2022

jonaslagoni commented Mar 17, 2022 •

edited

Loading

derberg Mar 22, 2022 •

edited

Loading

fmvilas Mar 22, 2022 •

edited

Loading

derberg commented Mar 17, 2022 •

edited

Loading