40
edits
Changes
2018 Scholarship Committee lessons learned
[[2018_Scholarship_Documents|2018 Scholarship Committee Documents]]
== Writing & editing ==
* Match requirements to call language to criteria.
* Consider whether “merit” is demonstrable and can be evaluated, or if alternative language cuts closer to what's actually happening.
* Copy edit EVERYTHING. If a date changes in one place, make sure it's updated everywhere else. This includes copy going out to mailing lists, text in forms, website content, anything posted on the code4lib wiki. ctrl+F 2018, 2019, etc. Everyone can help copy edit, but the buck stops with the committee chair.
* Thank sponsors in basically everything that goes out. List them first.
== Document management ==
* Collect preferred email addresses for e.g. Google Drive before starting to share folders and docs.
* Make clear which versions of a given doc are active draft, inactive draft, finalized.
* Try not to duplicate work - confirm a document doesn't exist before starting a new one.
* Create and bequeath organized documents for the next year's committee! don't make them start from scratch.
* Make a disposal plan for documents with personal information that shouldn't be shared with next year's committee.
== Privacy & security ==
* Ask applicants for the minimum amount of information needed to make decisions.
* Manage document sharing along a similar principle: Share documents (especially those containing personal info) only with people/accounts that really need access, e.g. only committee members need to see applications.
* Find a secure way to share logins and passwords OR use a reflector.
== Timeline ==
* Get familiar with timeline dependencies as early as possible and make sure everyone in the committee is aware of them.
* Make sure the local planning committee and anyone else responsible for setting the master timeline are getting information about and accounting for any work plans we set as a committee -- otherwise will default to a previous year's schedule.
* Pushing back on LPC decisions is probably okay -- test out earlier rather than later whether this is true.
== Clear communication channels ==
* Communicate from official account as much as possible, if using. Use it to send out call for applications, notify applicants, announce recipients, call for buddies, etc.
* Be clear in advance who will monitor new/shared communication channels (Twitter, Slack channel, email account) & answer questions. Who’s responsible? Who has time to do this?
* Set regular times to check in with LPC about committee status. Don't assume LPC remembers that your committee exists.
* Don't assume people are on email, Twitter, Slack, whatever at the same time you are.
* Respect people's time (fellow committee members, scholarship applicants and recipients, conference coordinators, other Code4Lib committees) by providing enough time to reply if needed, sending reminders, and replying promptly if at all possible.
* If you don't know, ask.
== Task distribution ==
* Clearly identify all-hands tasks, 2-3-person tasks, and 1-person tasks.
* Committee work will always involve someone taking on more than they're able to do, both out of wanting to help and also changing work/life circumstances. Have a contingency plan for when someone responsible for a certain part of the committee charge inevitably gets sick or has a jam-packed month at work. Make it 100% okay to communicate this and ask for help, and agree on how the handoff will work. Identify primaries and backups for each task. Prepare to adjust if it seems like one person is everyone's backup or ends up carrying all of the weight.
* LPC are dealing with tons of responsibilities and many of them are first-timers to event organizing and/or code4lib. If something needs attention, be extremely explicit about that and give a timeframe.
== Writing & editing ==
* Match requirements to call language to criteria.
* Consider whether “merit” is demonstrable and can be evaluated, or if alternative language cuts closer to what's actually happening.
* Copy edit EVERYTHING. If a date changes in one place, make sure it's updated everywhere else. This includes copy going out to mailing lists, text in forms, website content, anything posted on the code4lib wiki. ctrl+F 2018, 2019, etc. Everyone can help copy edit, but the buck stops with the committee chair.
* Thank sponsors in basically everything that goes out. List them first.
== Document management ==
* Collect preferred email addresses for e.g. Google Drive before starting to share folders and docs.
* Make clear which versions of a given doc are active draft, inactive draft, finalized.
* Try not to duplicate work - confirm a document doesn't exist before starting a new one.
* Create and bequeath organized documents for the next year's committee! don't make them start from scratch.
* Make a disposal plan for documents with personal information that shouldn't be shared with next year's committee.
== Privacy & security ==
* Ask applicants for the minimum amount of information needed to make decisions.
* Manage document sharing along a similar principle: Share documents (especially those containing personal info) only with people/accounts that really need access, e.g. only committee members need to see applications.
* Find a secure way to share logins and passwords OR use a reflector.
== Timeline ==
* Get familiar with timeline dependencies as early as possible and make sure everyone in the committee is aware of them.
* Make sure the local planning committee and anyone else responsible for setting the master timeline are getting information about and accounting for any work plans we set as a committee -- otherwise will default to a previous year's schedule.
* Pushing back on LPC decisions is probably okay -- test out earlier rather than later whether this is true.
== Clear communication channels ==
* Communicate from official account as much as possible, if using. Use it to send out call for applications, notify applicants, announce recipients, call for buddies, etc.
* Be clear in advance who will monitor new/shared communication channels (Twitter, Slack channel, email account) & answer questions. Who’s responsible? Who has time to do this?
* Set regular times to check in with LPC about committee status. Don't assume LPC remembers that your committee exists.
* Don't assume people are on email, Twitter, Slack, whatever at the same time you are.
* Respect people's time (fellow committee members, scholarship applicants and recipients, conference coordinators, other Code4Lib committees) by providing enough time to reply if needed, sending reminders, and replying promptly if at all possible.
* If you don't know, ask.
== Task distribution ==
* Clearly identify all-hands tasks, 2-3-person tasks, and 1-person tasks.
* Committee work will always involve someone taking on more than they're able to do, both out of wanting to help and also changing work/life circumstances. Have a contingency plan for when someone responsible for a certain part of the committee charge inevitably gets sick or has a jam-packed month at work. Make it 100% okay to communicate this and ask for help, and agree on how the handoff will work. Identify primaries and backups for each task. Prepare to adjust if it seems like one person is everyone's backup or ends up carrying all of the weight.
* LPC are dealing with tons of responsibilities and many of them are first-timers to event organizing and/or code4lib. If something needs attention, be extremely explicit about that and give a timeframe.