Summary

Issue#5

A new feature is wanted for allowing users to see when other developers are available to help. Users should be able to define their weekly availability and be able to see the availability for other users on the site. The UI should always display these time slots in the context of the current user's timezone.

Proposals

New ActiveRecord Model(s) for Representing User Availability

Proposal 1: Adding Schedule & TimeSlot models where User has_one Schedule

Add new models for a user's schedule. A user has_one :schedule and a schedule has_many :time_slots. The migrations to add these would look like:

# create_schedules
create_table :schedules do |t|
  t.references :user, null: false, foreign_key: true, index: { unique: true }

  t.timestamps
end

# create_time_slots
create_table :time_slots do |t|
  t.references :schedule, null: false, foreign_key: true

  # plan to implement as `enum`. Could also just use `t.string` with the day
  #   name
  t.integer :day_of_week, null: false

  t.time :start_time
  t.time :end_time

  t.timestamps
end

Pros:

  1. Increased flexibility with the 2 models for these concepts. There's potential to support a user declaring two separate, disconnected time slots in one day.
  2. All users' available time slots can be easily queried.

Cons:

  1. Comes with some increased complexity (leads to nested form).

Proposal 1a: Add Schedule & TimeSlot where User has_many Schedules

Add the same models as above in the first proposal except a user has_many schedules. The difference with the migration is that the schedules table will be created without a unique index on the user_id foreign key, allowing a single user to be referenced in multiple schedules:

create_table :schedules do |t|
  t.references :user, null: false, foreign_key: true

  t.timestamps
end

Pros:

  1. Allows users to have multiple schedules defined. This could allow the feature to grow in the future. One thing that comes to mind would be allowing the user to block out more than a single week’s worth of time when creating their schedule.
  2. has_many/belongs_to associations are, at least I feel, easier to work with. More predictable behavior, easier to reason about a lot of the time. And more familiar.

Cons: