Basic functionality

[jankramer]

Let's start thinking about what ARNOLD should actually do. Below is my vision, but feel free to comment or question any assumptions I made.

The problem ARNOLD is trying to solve is to make regular meetings happen more regularly. The reason this doesn't happen right now is that with reduced availability of every member, these meetings actually started requiring planning. A mundane task that is best left to computers.

For ARNOLD to calculate the optimal meeting dates, it requires some input:

• the availability of each member;
• the minimum number of members that should be available to hold a meeting.

Because some days are more preferable than others (e.g. weekends are more suitable than week days), I suppose the availability should not be a simple boolean, but should be able to represent preference.

The availability should obviously be provided by the users through one of the clients.

Then at a set interval ARNOLD calculates the next date for a meeting and asks each member to confirm the date. If everyone accepts the date, then everything is OK and beer, stories and Arnold movies will be enjoyed. If someone rejects the date, ARNOLD calculates the next best date. If ARNOLD is incapable of calculating a date because not all criteria are met, a failure notification will be sent to each member and the meeting will be postponed to the next period.

Any suggestions, additions, etc.?

[DuncanvR]

Sounds good!

I was thinking the availability could be set by distributing some points over the days in a week. E.g. everyone gets to divide 10 points; I could put 5 on Saturday and 1 on Monday-Friday. That would make the calculation of the most appropriate date fairly easy, as ARNOLD can just sum the points and pick the highest scoring date.

Because not all weeks are the same, I think the applications should allow a user to set a default distribution of those points, but also specify exceptions. E.g. this week Saturday is no good for me, so I'll redistribute my points to 2 for Monday-Friday, but only for this week.

Would that work from a user's perspective?

[DuncanvR]

After thinking about it some more, I don't think it should be done as I described earlier, i.e. by dividing a fixed amount of points over the days in a week. Instead, a user should be able to indicate his availability/preference per day. How about doing this similar to datumprikker.nl, with 3 possible choices per day:

• No (this day doesn't suit me);
• Maybe (not sure yet / rather not);
• Yes (this day suits me).
  Mapping these options to numbers still makes it very easy to determine the most appropriate date, by summing them for every user. As mentioned before, users should be able to set default values for certain days, so the system can use this default setting whenever a user hasn't set a specific availability.

Something we haven't discussed before is taking the host of a meeting into account. Basically, the host is a role that rotates over the users. Whoever was the host longest ago, should be the host for the next meeting. Even when the naive summing method picks a date on which most users are available, if the host has that day flagged as No another date will have to be found. Additionally, there might be times at which the host is unavailable, and there are several strategies to deal with that. Either the meeting is postponed (usually until the next week), or someone else volunteers to take over the role of host.

Another thing I'd like to introduce is the difference between a prospective meeting and a scheduled one. Both have a host, but only the latter has a date assigned.

Let's list the basic user requirements then.

• Flagging availability
  • A1: A user must be able to indicate his availability for any specific day in the future.
  • A2: A user must be able to indicate his default availability for all days in the future.
  • A3: When a user changes his availability for days in a week for which a meeting has already been scheduled, the host of the meeting must be notified.
• Meeting details
  • M1: The host of a prospective meeting must be automatically assigned to the user that was host of a meeting longest ago.
  • M2: The host of a prospective/scheduled meeting must be able to resign his role and assign another user as the host of that meeting.
  • M3: Another user must be able to 'hijack' a prospective/scheduled meeting to become the host.
  • M4: The host of a scheduled meeting must be able to cancel that meeting.
  • M5: The host of a scheduled meeting he must be able to suggest an alternative date.
• Planning meetings
  • P1: The system must set up a new prospective meeting a predefined number (probably 1 or 2) of weeks after a successful meeting.
  • P2: The system must schedule a prospective meeting whenever a suitable date can be found.

The granularity of A2 is still up for discussion; I'd opt for allowing the user to set a default availability for every day of the week, but I'm fine with an enterprisey solution that would allow the user to script his availability for any given day depending on the phase of the moon. The M3 feature is meant to only be used if the original host isn't reachable (and thus also not able to resign from being the host himself as per M2), but I trust users enough to always allow this. The P2 requirement should be defined more clearly; what exactly are the conditions for the system to schedule a meeting? Something like at least half the users must've indicated their availability? That might start leading it's own life when combined with A2. This should probably be configurable inside the application anyway, as opposed to a hard requirement.

BAM. That's that. Any thoughts/remarks/suggestions?

Cheers,
Duncan

[jankramer]

Excellent! I fully agree with the points you made. Also, I can't think of any essential requirements that are missing right now, so I think this is a good foundation for a minimum viable product.

Because we're planning on facilitating multiple implementations, I think it would be great to have a canonical and unambiguous specification of the ARNOLD server component functionality. It would be even more awesome if this specification is in an executable yet language independent format, so each implementor can test its implementation is actually compatible with the spec. This also forces us to keep the spec and the implementations in sync with each other.

Therefore, I propose to try out the StoryBDD style of specification using the Gherkin DSL as this fits these criteria. Gherkin is just plain English with a few rules to adhere, so we can all understand the specification and collaborate on it. Also, a lot of languages actually have an implementation of Gherkin (Behat (PHP), SpecFlow (.NET), Cucumber (Ruby), JBehave (Java), to name a few), so when implementing in a language that has Gherkin tooling, the implementation can be automatically tested against the specification. In theory, at least ;) But if the testing part doesn't work out, the specs can still act as documentation. What do you think?

Actually, now that I look back at the requirements, for a MVP we might actually postpone some requirements to a later version. M2, M3 and M5 for example are all features that are very convenient and should definitely be added at some point, but as long as they're missing, a host can achieve the same goal just by cancelling the meeting and let the system set up a new meeting. The absolute bare minimum of requirements for v1 in my opinion are: A1, M1, M4, P1 and P2. How do you feel about starting with specifying just these requirements?

[DuncanvR]

Love that way of defining requirements in stories --- a whole world is opening for me!

Not entirely sure of how to combine that style with Haskell development yet though; I could find only a handful of projects that deal with it, and little documentation about it. But, like you said, the specs can at least act as documentation.

And I agree with your suggestion about the functionality of the MVP (again, learning new things here; wasn't familiar with the term), so we can start adding those feature specifications!