Re: Design-stage advice and opinions welcomed

From: Gordon Burditt <gordonb.lizck_at_burditt.org>
Date: Fri, 25 Sep 2015 17:38:40 -0500
Message-ID: <F_GdnWoMTc1tUZjLnZ2dnUU7-ROdnZ2d_at_posted.internetamerica>


> a) You've used the phrase "typically" a future-proofing red flag alert
> that meetings might sometimes end up more than twice per month. And
> might you have virtual groups that don't even have formal physical
> meetings?

If you allow for up to 2 meetings slots for each group you have to allow for less than 2 meetings a month, so there needs to be a way to indicate "no meeting" in a slot. This same method could be used for virtual groups with no physical meetings. I prefer a meetings table, though.

An individual instance of a meeting should be able to have a title. If there is a speaker, this probably includes the name of the speaker and the topic. If there's a project being worked on, describe the project, e.g. "Raspberry Pi - Software for the Camera". This information probably has to be supplied by the convenor when it's available.  

> b) Will you ever need to check for group/venue/day clashes? If so then
> cross checking that will include 1st meeting for one group against both
> 1st and 2nd for another will become complex.

I would think that venue/day/time clashes would be more of an issue. Many venues have more than one time slot in a day for a meeting. Two groups might decide to meet together one time for a subject of common interest (e.g. a Raspberry Pi group and a Linux group, since the Raspberry Pi runs Linux), which is an exception to this.

You also have to deal with the 1st meeting in a month and the 2nd meeting in a month for the same group might clash. (e.g. 1st meeting: 4th Friday, 2nd meeting: last Friday). It might not be a problem, but you also don't want it listed on a calendar twice. It just might be that the first meeting slot describes a meeting with a guest lecturer, and the second meeting slot describes a work session where the participants actually build something. Which type of meeting happens on the overlap date.

> And for the "day", I'd consider defining it as a multi-column attribute
> of week-of-month and day-of-week so that they can be stored as just
> integer values, being mindful of regional differences in definition of
> DoW #1 being either Sunday of Monday.

Note that things can get complicated here: "last Friday of the month" and "4th Friday of the month" may or may not happen on the same day depending on which month it is (but they would presumably have a different code for week-of-month, since the formula is different even though the result might be the same). Also consider that some groups just might schedule meetings on the 5th Friday of every month, which doesn't happen in every month.

Do you need to support having a meeting on the Wednesday after the first Monday in a month? How about the Monday after the last Friday of the month, which just might end up in the next month? Do you want to support meeting every Friday the 13th? (happens 1-3 days a year; I don't think 0 or 4 in a year can happen with the current calendar).

> I note in a followup posting that you might code for Xmas, etc. whereas
> I'd possibly recommend creating a "holidays" table as well, to cater for
> one-off venue closures (4th July?) and the moveable beast that is
> Easter.

Is Easter really a problem if you don't schedule meetings on Sundays? Meetings on Sundays tend to conflict with family together time and some religious attitudes (unless it's a church-related group), and people seem to hardly ever schedule meetings on Sundays for those and other reasons. Also, it seems that if a venue has any day of the week "closed", it probably includes Sunday (unless it's a church).

I'd like to also suggest that "holidays", or whatever else you might call certain conditions that prevent meetings from happening, can be group-specific or venue-specific, and they might pop up without a lot of notice.

For example: a NFL-oriented group will probably not have many members show up at a meeting on the day of the Super Bowl (unless perhaps the venue has a gigantic-screen TV that receives the game, and allow attendees to bring their own beer and snacks), so they might reschedule that for the next or previous week if possible. A Linux User's group probably wouldn't care about the Super Bowl, but they might want to reschedule if there's a local Linux Fest going on. A non-Christian church group might not care that a meeting is scheduled on Christmas or Easter.

You might get a couple of weeks notice that the venue is having construction work done and is closed during specific (or perhaps not so specific) times. You might get less notice about fire damage and even less about (unplanned) power outages or weather that makes travel dangerous. Perhaps there's an alternate venue or perhaps it will be rescheduled or just cancelled.

I attend several groups that meet monthly. Generally the best you can get farther out than the next month is a *tentative* date, which is accurate maybe 80 - 90% of the time. If there is a change for a meeting in month X, it will probably be decided at the meeting for the prior month by a group vote (if you didn't attend that meeting, you can find out on the group's web site and/or email is sent out in advance of a meeting). Or, it will be announced that the venue isn't available, and there might or might not be alternate dates or locations available.

There might be a "work cycle" involved in maintaining the database. Every so often, such as once a month, a list of meetings in the next, say, 3 months for a group is sent to the group's convenor. The convenor should confirm, edit, or cancel the meetings or add some. Care should be taken that the calendar rules don't undo manual edits.

Think about what should happen if you are informed in December that, effective next April and continuing indefinitely, the group is switching from meetings on the 2nd Tuesday to meetings on the 3rd Tuesday, and at the same time is switching venues. You'd better not change any meetings to come *before* April, you should immediately stop showing incorrect meetings that happen in April and later and show the correct ones instead. Perhaps those "Nth <day of week" formulas need a start and end date. Received on Sat Sep 26 2015 - 00:38:40 CEST

Original text of this message