Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: simplify meetings scheduling #297

Merged
merged 7 commits into from
Mar 23, 2022

Conversation

derberg
Copy link
Member

@derberg derberg commented Mar 17, 2022

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:

Screenshot 2022-03-17 at 11 46 58

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

Screenshot 2022-03-17 at 11 56 44

Example issues created with new workflows are here: https://github.com/derberg/test-experiment/issues
Screenshot 2022-03-17 at 11 58 24

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
Copy link
Member

jonaslagoni commented Mar 17, 2022

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.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fmvilas ping 😉

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@derberg derberg Mar 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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 😆

Copy link
Member

@fmvilas fmvilas Mar 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🙏

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 👍🏼

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@derberg
Copy link
Member Author

derberg commented Mar 17, 2022

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
Copy link
Member

@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
Copy link
Member Author

derberg commented Mar 17, 2022

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
Copy link
Member

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
jonaslagoni previously approved these changes Mar 17, 2022
Copy link
Member

@jonaslagoni jonaslagoni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@derberg
Copy link
Member Author

derberg commented Mar 17, 2022

@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 derberg requested a review from fmvilas March 17, 2022 17:08
@derberg
Copy link
Member Author

derberg commented Mar 23, 2022

/rtm

@asyncapi-bot asyncapi-bot merged commit 6ecdff8 into asyncapi:master Mar 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants