It’s come up recently that we might consider revising our logo. I saw a coworker playing around with it and thought I’d give it a try. Continue reading “Musing: Playing Around with the NNELS Logo”
Lightning talk followed by workshop and breakout discussion. Continue reading “Code4Lib North: Day 1 Afternoon Notes”
Morning presentations Continue reading “Code4Lib North: Day 1 Morning Notes”
Want to talk about communities and community building. It was a partial contextual shift as to her place in a number of communities.
Thought a lot about where she fits in. Have had a lot of identities, and thinks of herself as: nerd, geek, wonk, curator, archivist, woman, leader. Originally thought of herself as just another person, but everyone in this room should take on the role of leader.
Everything we do is part of the community, everywhere. Everyone in code4lib is part of a
community that succeeds through relationships.
Take the ethos of code4lib back to each organization.
Every software requires a community. Each person is part of it cares. Sustaining software requires a community of people who really care. We need to think about who uses our software. This
community is not just about people who write code,
it’s also about people use the software.
The most important thing is to work with those groups of users.
These communities are built using communication, inclusiveness, consideration, even more communication, and sense of ownership.
Need to think about users, stakeholders, researchers.
Everyone should read this blog post on backchannel conference talk.
Seen projects fail because they’re shared with the world but no one really takes ownership. Ownership goes both ways. Owning what you release, but also helping other projects be a success. Not everything fails, but it needs a community to thrive.
This is what we’re looking for in our communities and in our projects.
That they thrive.
You want a community that participates, looks out for each other.
What Defines a Successful Community or Project?
Participation. One project was a massive failure because no one participated.
Enthusiasm. Who would even want to fund it?
A sense of pride. ‘I’m part of that, made it happen, succeeded in part because of me.’
Learn from the history and the people who can be your mentors. Look at what you’re doing and what came before. Part of inclusiveness is acknowledging that you’re not the only person who has ever worked on the problem, who can work on the problem.
Adoption. A sign of success is that they’ve take it, use it, and contribute to it.
Now we will discuss.
This supposedly not shy group, but is actually shy a lot of time.
Do we not think we’re not ‘real’ coders? Have the self imposter syndrome. But actually, she is a coder too.
Why does this community has to self-organize? Actually, awesome that this community has self-organized. Used to think every collection is unique and not doing the same thing, but we’re seeing emergence of communities that are realizing this is not true. For example, linked data community cross-fertilizing regardless of the type of collections they had. We self-organized was a sense of shared problem and shared passion.
No one organization can do it alone. We all need to work on it together.
Two most attributes to fail projects. One person thought it was a good idea, but no one else knew they were working on it. It didn’t succeed because there was no sense of participation, because no one was invited to participate. No one should work alone. We fail because we don’t collaborate.
How do you convince someone that they are a leader? Tell them that they are a success.
How do you adopt something when the leaders are not on board? ‘But everyone else is doing it, dad.’ Adoption by others. It’s really hard to be the first one though, we know.
Data-Driven Documents: Visualizing library data with D3.js
Bret Davidson, North Carolina State University Libraries
Being a smaller session, there was a lot of tangents and what not, so apologies if the notes seem a little disorganized.
How do you measure “value” or success of projects in library setting where ROI is not measure in the amount of money?
Some Flavours of Failure
- technical failure
- failure to effectively address a real user need
- outreach/promotion failure
- design/UX failure
- project team communication failure
- failure to start
- launch failure
- no usage
- missed opportunities (risk-averse failure)
Most of these issues boil down to a break down of communications of some sort.
What does a Project Manager Do?
Sometimes the problem is not knowing what a project manager does. The person who comes up with the idea thinks they run the project; think that they know everything to make the decisions. Or, they become the one dictating all the requirements.
A lot of the issues are political. No way to move it over to having systems oversight.
Making the Distinction?
Project manager is in charge of day to day operations. Project lead is thinking about high level requirement, more strategically, and becomes liaison between systems and the rest of the library. (e.g. public services project, would have public services librarian) Decisions are made collaboratively.
Once it settles in, make an oversight team for maintenance purposes.
The Culture of Process
Product is the reflection of the process? But, want to see evidence of process. Without ‘evidence’ of the process, what about accountability and transparency? The evidence can also be a good reference so that you don’t have to explain.
Get people to meet to discuss what they’re going to do. Can cut down a lot in the amount of time spend doing things that aren’t needed, and waiting for dependencies.
Staff frequently also think they know what users want better than users.
Project FUBAR Lightning Talk
- Islandora + digital repository initiative on campus
- Sierra – ILS
- Islandora: lots of delays in development
- ILS: had to go beta early
Option for Failure?
- mission critical projects, must be salvaged
- how to deal with other people’s projects failure – vendors didn’t deliver
- plan for the worst before the worst happens
How to Successfully Survive a Mandated Project
- practice good communication
- know the political ramifications of your actions to yourself and the chain of command
- work to manage expectations
- be prepared to clean up any messes and make any changes
- Souce: Ellern, Jill. “How to Successfully Survive a Mandated Project,” Computers in Libraries 31, no. 9 (Nov 2011): 16-20.
The Right Approach
This is a reference to the Dilbert comic called “The Right Approach”, which a porcupine says that “we must stick them with quills – it’s the only way!”, because the ‘correct’ approach in any situation is the only approach you know.
While the project I worked on wasn’t quite like this, it was more the ‘the status quo’ is the best approach.
- “seagull manager flies in, makes a lot of noise, craps on everything then flies off again leaving a big mess behind” -urbandictionary
Examples – Fail Projects
Never went live
- statistics dashboard for collections and services
- web app to add photo information to specific photo collection
Fail by Bloat
- Instruction workshop scheduler – supports weird business rules
- building diverse teams
- expecting dead ends
- having fall-back plans
- learn to say ‘no’ (preventing project creep), list features and possibly impact and complexity
- fault-tolerant schedules
- establishing flexible goals at the start
- making sure it fits in the strategic plan (helps with funding)
- prototype/drafting to make sure it’s feasible
- make product resilient, assuming someone will try to break it
- launch checklist by VCU
It’s All About Communications
Need to communicate with the staff. Present and allow feedback. Need to give people an outlet to provide feedback and response to feedback. You don’t need to implement most of it.
Don’t assume that the person is ignorant, dumb, or just out to get you. You’re not always right, and sometimes ideas are tossed in just to make people think.
When a Project has Failed
Do a post-project review and go over the failure points. Post-mortem meetings can be very cathartic (even if it ends up being a rant).
Learn from your mistakes. You should always do this even if the project didn’t actually fail.
Now it’s back to braving the cold at the end of the pre-conference day.
The librarians had a half-day workshop where the activities focused on how we can communicate the value of librarians and the library to the rest of the university. Continue reading “Workshop: Communicating the Library’s Value in Academia”
UPDATE: See my more recent blog post if you’re looking for my supplement materials (to the Ryerson Google site) on sync’ing Google Apps.
I attended a session to address concerns with privacy and security concerns in adopting Google apps at the university. Half of the session was actually a general how to protect your own information and your responsibilities as a user. I’ll focus more on the project itself than the second half since there’s a ton of resources about protecting your information already out there.
For the implementation, Sada Systems will be dealing with the actual implementation and migration. Roll out will be done in stages starting with the first four, and the rest will have to go through the evaluation process first.
- app engine
- Faculty and students will have an opt-in option for mail.
- Staff, however, will be migrated (i.e. not optional).
- Everyone will be moved to calendar in order to be rid of Groupwise (yay!).
- Everyone will still keep their @ryerson.ca so there is no change in the email address itself.
Timeline & Next Steps
In a nutshell, there is none, and that’s because the legal agreement hasn’t actually been signed yet.
Once it does get signed, then alpha testing will be done with the CCS group (central IT) and then beta testing with a larger community group. They’re still hoping for a fall rollout though.
Most privacy and security concerns revolved around lawful access and warrantless searches with storing data in the US. It was explained that basically, it doesn’t make a difference. Canada has similar legislation and the Mutual Legal Assistance Treaties (with many countries) is a binding agreement to share information under lawful access or warrantless searches, which means the same thing will happen if your data is stored in any of the countries part of the agreement.
Privacy & Data Protection
To alleviate some concerns, the organizing group assured everyone that a Privacy Impact Assessment is done using the international standard, Privacy in Design and ensures that there are no breaches to:
- Ontario Freedom of Information and Protection of Privacy Act
- Ryerson Information Protection and Access Policy
- Execution of Contracts and Documents and Signing Approval Authority Schedule
- all incoming mail goes through the university servers first
- not opting in means that email stays on the university servers
- opting in means the emails are then sent and stored on Google servers
- students emails will not be visible in the global (internal?) address list
- minimum identifying information (username, name) is used for authentication
- drives/docs is private by default
- calendars display only free/busy by default (as in Groupwise right now)
As I mentioned, in the second half of the presentation, we were all reminded that most email/information/data breaches are due to users, not email systems or hardware, and that email is not secure (although they’re looking into encryption for sensitive information). We got the usual spiel on our responsibilities not to include sensitive information in emails, having secure passwords, being careful of phishing, making sure websites use https, etc.
We’ll see how quickly they get things going, but I’m sure many staff will be happy to get rid of Groupwise (which likes to crash at least a couple of times a week and cancels shut down) at the very least.
For more updates, there is a dedicated blog for project updates.