Latest revision as of 12:26, 2 July 2010

Things we should change with freehub

Objectives

• Centralize data
• Address the important stuff
• Make it functional for people, so they aren't tempted to use other systems
• Clearly distinguish between activities and roles and services, and add more granularity to the data
• Better reporting of our membership
• Better reporting of our class attendance

next steps

• [x] review this list for sanity
• [x] send to the IT Cluster for LoE scoping
• [x] Prioritise the tasks
• [x] send to the other Co-ops using freehub for feedback
• [x] send to the listserv for feedback
• [ ] put a timeline on the features
• [ ] develop an education plan
  • Put this in the greeter guide
  • enforce the changes

Existing Problems

It is hard to identify different member types and what rights they have

We can't always tell who are youth members.

Solution : Define these roles better, put this info somewhere visible in freehub

Define to people what the following mean. they only make sense once you understand the rest of FreeHub

• patron
• staff
• youth (under 18)

ALON: Do you see these as mutually exclusive? Don't we have both patrons and staff that are youth? On the details page for a person we ask for (optionally) year of birth. The intent was that for all people under 18 we want to capture their year of birth. I believe Jessie requested this a year ago or so. We don't capture this consistently b/c greeters do not know that they should do this.

That said, clarifying patron v. staff or coming up with a clearer designation is certainly a good idea.

It is hard to tell who is working in the shop, who is visiting and who has digging rights

Solution : Define the states on the sign in page, educate the greeters so they know which buttons to press

Solution : Highlight people who are Staff mechs for that shift in the 'in the shop today' list

Solution : Highlight people who have digging rights

Solution : Sort and group these lists

When someone is in the shop they could be any of :

• Visiting
• Volunteering
• Staff mechanic (instead of just staff hanging out in the shop)
• Attending a class
• Greeter

Alon: this is a good one for discussion. It intersects heavily with the Role comments above.

We also need to be able to group the lists of who is in the shop

• group people by their type
  • staff
  • digging rights
  • volunteers
• add an 'add note' link from this list

Alon: good ideas. I've also thought that list could better represent what is actually going on.

It is confusing and not always logical to track certain rights that people have

Solution : Add 'tags' to a member, allow for the ability to sort and search lists by tag

This will allow us to track and maintain any of the following

• Staff in training
• Volunteer hours
• Active Volunteers
• Youth
• Active digging rights projects
• people with outstanding issues
• Key holder, so we can track issue and expiry times.
• a 'title' to staff or patrons so they can be
  • greeter
  • in training
  • whatever label they like

Alon: I believe I understand the desires here. My concern is practice in the real world. Are we really prepared to track all volunteer hours in Freehub? Isn't the card system working? For key holders, wouldn't a wiki page work fine? I don't think the issue is that Freehub can't track it. It think the issue is that there is not a person or process responsible for the tracking. Once we get that sorted, there may be incremental benefits to getting it in to Freehub at which time I think we consider it. I'm definitely open to being convinced otherwise.

We don't have decent tracking of memberships and attendance

Solution : Define what the options are for 'add a service' on the users page

Solution : Sign in all staff

Solution : Enforce zip or phone when you create digging rights

Solution : Enforce membership before digging rights can be added

Solution : Enforce the liability form before a membership can be added

This will help us to report on different patron/member types and make sure that the services are added with the correct dependencies

• identify when a memberships as a renewal or a new membership
• enforce some required fields. ZIP and PHONE (or email)
• add a Youth (under 18) field.
• flag to show if the liability form was signed
• check people into classes

Alon: a few comments...

Yes, all mechanics should sign in. This is just policy/practice, right?

Freehub knows when a membership is a renewal if there is already an earlier membership. We don't need to capture any more information. Do you want to show this in the UI somehow?

The only field we require is name. This has been largely an age old privacy concern at the BK for general attendance. However, we do ask for more information for members. Maybe what we want to do is require more personal information for members.

There is a Year of Birth field already. A Youth flag doesn't quite make sense as someone will have to manually remove the flag when they turn 18 and that's never going to happen.

If we add class services for each person when they sign up for a class then sign them in to the shop when they show up for the class is that not sufficient? This is what I do when I teach a class but am pretty sure that other teachers do not. Isn't this another policy/practice issue or is there something else you are hoping to achieve?

=== We don't always see important notes that are attached to a person, after a period of time they are no longer displayed, or get replaced by a later dated note.

Solution : Add an extra flag to a note ('sticky') that means it will ALWAYS be displayed regartless of it's age or position in the note list

Alon: notes do automatically get the current date/time. What is missing?

Also, I think I need more clarification on the "sticky" desire. Is that showing the most recent note or something else?

Better reporting (later)

This can be addressed once we start using tags and some of the other proposed solutions.

• summary report

Create a new report that lists memberships per week/month and if they were volunteer or paid for and if they were a renewal.

explain the columns on the 'summary report'.. 'Patron' overlaps with other values.

break them out as : TOTAL, Staff, MEMBERS, non-members, youth , ( and volunteer as an additional # AFTER the TOTAL)

• Visits report

group each user, report the number of visits in the time period

• People report

list if they have a membership and the start date of that membership

• services report

group all services under one person for a date range

Add new reports

• Current volunteers  ? why
• current staff in training how do we identify these people, do we need it
• Current digging rights owners - can be done today, just document it, link to it
• Current keyholders - active staff - TBD
• expired members (so we can actively renew them)

Alon: I love the interest in more reporting. One question to consider for each of these is who is going to run the report, for what purpose and to share with whom. That will help me understand the need behind the report and how it should be designed.