LD4 Community Engagement Project / Group Name

See here for getting started with this template: https://github.com/LD4/LD4_Engagement/wiki/LD4-Community-Engagement-Group-Project-Template:-Getting-Started

About

Linked Data for Libraries, Linked Data for Production, and Linked Data for Libraries Labs are a series of grant-funded projects working broadly on implementing Linked Data in library workflows across functional areas and domains. The umbrella effort is referred to as 'LD4'.

Enter here a short description for your project or group. This is what people will skim to know if they want to be involved or not.

Conveners:

• List the conveners name, GitHub username and email here.

Scope

short description of the scope of this project or group.

This project/group is an effort to:

• enter your motivating needs, identified work areas or proposed artifacts

Add any specific term definitions you may want to clarify for your group or project here.

Optionally, you can also include some indication of why this group formed or the motivating use cases for the project.

Participants

The group is open to [indicate who can take part - public, LD4 Community, LD4 Partners, Specific Application Developers, ...]. Here is a list of open issues or work needs for folks to see how they can jump in: point to where you are planning and monitoring work - issues, project board, etc.

list out the name, GitHub usernames, and emails of participants. Invite new participants to add their name via pull requests.

Working Areas

Proposed Outputs

list your proposed outputs or artifacts for this group here. Being clear on what you're working on will help the work progress and avoid frustrations.

General Timeframe

For group outputs: Enter your proposed timeframe for smaller, scoped work outputs.

For larger group planning: Plan on an assessment at 1 year (or earlier if things seem to not be working). The 1 year mark is a time to rotate conveners, choose new meeting times, refresh the goals, disband, morph, etc.

Workspace & Communication Channels

Primary Workspace (Notes, Outputs):

• This GitHub repository (the conveners, listed above, can give you write add you to the repository's team). Please follow this GitHub Repository's Collaboration guidelines.

Communication:

• [Regular Video calls (bi-weekly, depending on work) for updates on work] link to a single GitHub wiki page with meeting schedule, video call information, and agenda/notes
• Github Issues on this repository for work-specific discussions or questions
• Github Projects on this repository for project management
• Github Wiki on this repository for meeting notes & other documentation that isn't in the repository
• LD4-Community Slack Channel for informal discussion. (include a link to the slack channel and the signup form)
• Google Group Email list as needed: We recommend that you use your project or groups' GitHub Repository as the primary place for communication and collaboration, but an email list is helpful is you need to communicate there on anything more than general announcements. If you add an email list, be explicit about which communication channel is considered the communication channel of record.

Expectations of Participants

We recommend you include this as well as a link to the LD4 CoC

In order to create an inclusive, safe, and open work environment, we ask that all participants follow the LD4 Code of Conduct, in particular, a set of rules designed by the the Recurse Center, previously the Hacker School. In their own words, 'the goal [of the Recurse Center Social Rules] isn't to burden everyone with a bunch of annoying rules, or to give us a stick to bludgeon people with for "being bad." Rather, these rules are designed to help all of us build a pleasant, productive, and fearless community.'

As such, these four rules are a lightweight set of explicit social norms to curtail specific kinds of behavior found to be destructive to a supportive, productive, and fun learning/working environment. The four rules are listed here; you can read more about them at http://recurse.com/manual#sub-sec-social-rules.

1. "No feigning surprise." You shouldn't act surprised when someone says they don't know something. There is no benefit to feigning surprise, and regardless of intent, it makes someone feel bad, or worse, about admitting that they don't know something.
2. "No well-actually's." This is when someone says something almost, but not entirely correct, and another person responds with "well, actually," and gives a correction. That's not to say we don't care about truth or precision, but there are better ways to communicate this.
3. "No back-seat driving." If you overhear other people working through a problem, don't just intermittently toss advice in without engaging.
4. "No subtle -isms". This last rule bans racism, sexism, homophobia, transphobia, and other kinds of bias. Subtle -isms are small things that make others feel uncomfortable, and might be familiar as they're under the term "microagressions."

Tip of the hat here also to Mark Matienzo, who wrote the additional text explaining each of these rules in the context of a collaborative environment. We've paraphrased Matienzo's comments here.

Questions or Comments?

Use Github Issues on this repository (include a link to issues) or get in touch with one of the conveners. Include other communication channels here if something else is deemed the channel of record.