to a single table, and make multiple people selectable. Selecting multiple people and updating their status is probably more important than AJAX updates, but both would be awesome.

As discussed with @kgf , I'm going to attempt to convert the whole test suite to RSpec.

There should be two narrow columns for attribs division 1 and division 2. These columns should be click to sort.

This does not need to happen just yet, but very soon.

https://github.com/airblade/paper_trail

@kgf pointed out that we need to do this. I'll attempt to tackle it after converting tests (see #54).

We should write tests for this first

When you create a new person, for example, all the fields are relatively short, and are not well laid out.

It is currently changed in the form as a new label, but I would prefer it to be changed on the backend, in the database.

Please add a field for 'application date' to person. Field should be date format.

Story:
This is to record when a new person has applied for the department. The field exists on the application form and would help us track if an application stalls.

This may be due to json being included now.
A possible solution to this is creating a ruby version file to specify Ruby 2.1
We can stay on 2.1 for a bit

I dunno, ruby 1.9 hash syntax is a real thing, but bundler is not working for me locally.

18 lims(* master)➦⮀ ruby -v
ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-darwin14.0]
19 lims(* master)➦⮀ bundle -v
Bundler version 1.7.4
20 lims(* master)➦⮀ bundle exec rails c
Gemfile syntax error compile error
on line 49: syntax error, unexpected ':', expecting kEND
...ery-datatables-rails', github: 'rweng/jquery-datatables-rail...
                              ^

http://bundler.io/v1.7/man/gemfile.5.html suggests the hashrocket syntax for specifying a github source.

i was editing a already existing person. when i went to save i received

unknown attribute: phones

this is probably related to the recent work in channels apposed to phones.
app/controllers/people_controller.rb
line #122
if @person.update_attributes(params[:person])
https://github.com/kgf/lims/blob/development/app/controllers/people_controller.rb#L122

Expired certs should still be shown, but they should not grant the skill.

They are pretty much random right now.
One question is "Should different sections sort differently ?"

One slight challenge to this is the sections after the first (available, scheduled) are timecards, which have a relation to a person. The person has most of the info we would want to sort on...

This is basically a passport style photo. By Authentication, I mean that someone looking at our system knows who they are looking at in front of them.

Then you could better tell one person from another.

Items could belong to the highway department or the Department of Public Works. The item should know what department it belongs to.
This should be a required field. Department should be a new object.
Department menu can go under admin

A bunch of tests fail saying PhantomJS needs to run properly on my machine. Which it doesn't.

➦⮀ phantomjs
-bash: phantomjs: command not found

It would be good to have instructions for running the project, including tests.

Conceptually it makes no sense to me as a newb that a Title has skills. It feels more like a "Role" or a "Capability Set" or... Yeah, Title doesn't feel right, but I can live with that if it had a wiki page and / or an inline comment explaining the thinking.

This should closely match #13, but should come after that issue.

I am not all that comfortable writing tests for JS. This function uses jQueryUI to dynamically add additional fields to enter a new phone number or e-mail address.
It would be good to have some tests to ensure this all works.
Let me know if this is something you're comfortable with, or re-assign it to me and I'll do some research on it.

Current picker does not show time properly.
This is another possibility

http://tarruda.github.io/bootstrap-datetimepicker/

FEMA ICS uses a resource type code. We need to capture that code for each item. The choices for the item should come from instances of a different model. This should include a status field, so that ResourceTypes can be turned off if they do not apply.

One of the prime reasons to track items is to be able to accurately account for their use during a disaster. Different configurations of items will garner different reimbursement rates. I see three scenarios.

1. The easy one... A thing is used as is. An example is a towable lighting unit. We track it as an item. it has serial numbers, it has no accessories. It is self-contained.
2. A group... For example, we might have a Ford F350 truck, which is reimbursed at a specific rate. If it has a plow attached, it is a different rate. If it has a sander, it is a different rate. And if it has a plow and a sander it is another rate. Oh, it's a 9 foot plow ? Different rate ! In this scenario, we will track the accessories, such as the sander and the plow.
3. The equivalent of M&Ms... We can be reimbursed for the use of traffic cones, but we don't want to track each cone, that's too much work. "Hey, we need to find Cone 42 and 743 ! Start looking..." is not likely. If at the end of an event we know we started with 50 cones and we end with 50 cones, that's good enough. I am currently thinking this would be a group of 50, like scenario 2. I could create 50 cone records, but not concern myself with which is which.

This should make the inventory menu item a drop down, and add "New Item" to the bottom, just like people.

These QR codes would allow people to show themselves available for events from their smartphone or tablet. Authentication (who is signing up for the event) might be through a cookie on the device ?
There are two aspects to this. The first is creating a QR Code image associated with an event and adding that to the view. The second aspect would be to respond to the URL encoded in the QRCode, and allow people to volunteer for an event.

This would probably involve the utility qrencode. It is available in most linux repos, and is available in Mac OSX via brew install qrencode.

I would like to have a QR code show on the person show page, so that someone can use their phone to scan and have them added to their contacts.
This would probably involve the utility qrencode. It is available in most linux repos, and is available in Mac OSX via brew install qrencode.
The toughest part of this may be to determine WHAT should be encoded so that both Android and iPhone devices recognize it as something to be added to the contacts list.

When someone runs the application locally, they have to go into the console to give themselves admin rights before they can do anything.

Hook into Devise so that the first user created has admin rights.

There is an issue regarding the version numbers of deise, perhaps interacting with the versions of Ruby.

Also test-unit gem !

This will be used to allow decisions on inspections and grouping.
For example if there is a truck of type Ford F-250, you would have inspection questions about checking the transmission fluid, and you could group it with a snowplow mount. An item with the Type of Towable Lighting Unit would include inspection questions about the condition of the mast cables, and would not accept any groups. Model should include status, so a type can still exist, but not be available for new items.

When a grant is awarded, information often needs to be tracked. When was the grant awarded, when does it sunset, and what items were acquired with it ?

This will require a new object model, Grant.
name:string A short bit of text that will be used in the views and in the selection choices on forms
description:text A longer decription that can go into details.

Items will need to be modified to include the grant_id.

To make it more inviting for new contributors to get involved, it's good to reduce the barriers to entry as much as possible. I forget where I saw this first discussed, but basically, it's good to give people the positive experience of an accepted PR rather than bringing up obstacles that could have been avoided by providing requirements & guidance up front.

The convention seems to be to add a CONTRIBUTING.md file, (e.g. rails, rust, rubygems, factory-girl-rails). Then link to it in the README.

Requirements and general guidance can help whether someone is reporting an issue or coding. Specifically for coders, we can add anything that would help their PR get accepted.

E.g. if we want to suggest (or require) rubocop review, we can add the .rubocop.yml file to the repo. One benefit is the contributor can work on their code without waiting for human response, until they know that the PR won't (shouldn't) be rejected for style / complexity / etc. issues. Maybe we can add that requirement to CONTRIBUTING.md and then configure the .rubocop.yml file to trim down to a minimal level of requirements?

I like providing feedback on PRs if that's what contributors want, so perhaps the CONTRIBUTING.md could say "if you would like detailed feedback, add flag "feedback welcome" to your PR".

When setting a person's status to inactive, set all future timecards to ineligible, with a reason of inactive.

When entering an item, after selecting a department, only that departments locations should be available.

This would allow more API stability than using Google. Also, it would work without Internet access.

Currently inspections are intertwined with repairs, but I feel this is incorrect. Inspections are their own object. Also, the UI for inspections should be mobile first.

This would use something like Github's heatmap. There would be different color markers for when someone had worked, when someone responded that they were available, et al.

This is a great visualization, but it is a nice to have, thus a low priority.

Time cards should be created for everyone who is active, even people who are ineligible for that event. Timecards should not be created for people who are inactive. Timecards should be created for people who are on a leave of absence, but they should be set to unavailable, with a reason of Leave Of Absence. Creation of timecards should be on demand. You can create timecards more than once, and people who do not have timecards get timecards. When creating timecards, present a list of departments, and ask for the default status for each one. Departments are defined as an attribute on a person. Use this to create cards for all. Default status values could be ineligible, or unknown. All values should be possible.

What might be best is to print it out as landscape, and re-orient the division 2 values horizontally. I'll try to come up with a mock-up.

Some love and attention. UI Links should be from the person page, so that it's apparent who the contact info is connected with.

Currently there are two problems, one is the UI for entering them, and the other is that null ones are getting added.

Note users log-in and edit and update people. People model does not login.

Some events require a certain level of training, which is contained within the team they're on. When creating an event, have checkboxes (perhaps) to say which departments are eligible. Departments that are not eligible have availability records created with the status preset to "Unavailable", and the reason set as "Ineligible". This would greatly reduce the effort for setting up events. This expects that the changes in time tracking that are described in the Wiki are already implemented

There should be as many ways as possible for people to update their status. Two ways would be to use a barcode tag or a proximity card. This could be implemented using a Raspberry Pi, which could monitor either a proximity card reader, or a video stream from an attached camera. Once it has recognized the presence of one of these tags, it should do an http POST to show this event.
Things to include in the POST:

• Raw data from reader or barcode
• ID of the raspberrypi
• Source of the data (prox reader, video stream, some other scanner, bluetooth, wifi sniffer, et al)
• Timestamp of the scan. (This suggests that the pi will need to know the time, which may be tricky)
• Some category field, to show that this is a scan. The Pi might also send info POSTs, such as the temperature, or the battery voltage. or anything else)

Please feel free to comment !
@townegr

needs more favicon

How about

An example of the data would be setting up an initial user to allow logins.

http://arshaw.com/fullcalendar/docs/event_data/Event_Object/