DSG Procedures

From Digital Scholarship Group
Revision as of 13:56, 25 May 2017 by Alevesque (talk | contribs) (→‎Student Employees)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Identifying a DSG Project

The DSG has established a set of criteria for assessing new project applications to make sure they fit with the mission of the DSG. These criteria are listed on the DSG Policies page.

New Project Applications

Podio App and Web Form Submissions

Initial contact may be made through multiple channels. Our website routes applicants through a simply contact form, or applicants may email DSG members directly.

Next, DSG members should set up an initial meeting to get more information. They might use the intake questions (listed below) to frame that meeting, or email those questions to faculty ahead of time, or have a much more casual conversation, depending on what seems appropriate.

All new project applications are submitted via the Podio web form located on the DSG website at http://dsg.neu.edu/projects/new-projects/project-application/. The Podio app is located at https://podio.com/neuedu/digital-scholarship-group/apps/projects and can be modified as needed. This creates a proposed project card in Podio.

For easier tracking of new submissions to Podio app, follow the app by checking the box located in the sidebar below the name of the app and make sure that your account is set to send you email notifications if anything happens in anything you follow (go to My Account > Account Settings > Email & Notifications ).

Next, the group will discuss the project at a weekly meeting, and decide whether to accept.

Communications Templates

Communications templates are likely needed for emails that can be sent when the DSG receives a new application and either accepts or rejects that application. A draft for the email to be sent when a project is accepted has already been added to the wiki. The email to be sent for projects that do not meet the criteria of a DSG project should be sent an email with links to resources that can help them develop their project.

New Project Intake Interviews

Confirming Date and Time of Intake Interview

Once a date and time for the intake interview has been decided, the current coordinator should send an email confirming the date and time to the individual who submitted the application, and invite the appropriate subject librarian. An template for that email is located here. Please make sure that the following set of questions is attached to the email.

Questions for the Intake Interview

General Project Information

  • Project Name
  • Project Lead
  • Department
  • Anticipated support needs

Intake Interview Questions

  • What is the subject of your project?
  • What types of data are you working with?
  • How will this data need to be modeled and managed?
  • What is the anticipated duration of your project?
  • How long will you require the services of the DSG?
  • What are the major phases of your project?
  • Who is the audience of this project, and what is its size and scope?
  • How will your project be funded?
  • What are the specific goals of your project?
  • Which goals are considered time sensitive?
  • What prior skills, knowledge, or expertise do you have involving digital scholarship?
  • Will you need access to any specific types of training via the DSG?
  • Is there any other information about your project that the DSG should be aware of?

During the Intake Interview

  • Briefly discuss the DSG's philosophy of funding, and encourage prior planning and good communication for grant applications that might involve the DSG. Our philosophy is: community projects contribute to infrastructure, reduce use of fractional staff, cost-share, plan ahead and consult with us. Plan ahead means four months ahead. (A more formal statement of this philosophy is under development.)
  • If appropriate, share our suggested practices document, including analytics and search placement, and outline DSG support in that area.
  • Briefly discuss data management as a goal, bring sample plan. Reassure project that we will help with this, and that it is part of a long-term preservation strategy.
  • Create a Podio record for the project.

After the Intake Interview

  • Send our suggested practices document.
  • Set up follow-up meeting to develop data management plan and discuss preservation options with Archive-It.
  • When project websites are established, send project standard website analytics package (code and login from library account)
  • Invite projects to yearly grants town hall.

Service Requests

General Service Requests

The general service request form is located on the DSG website at http://dsg.neu.edu/resources/service-request/. The app can be found on Podio at https://podio.com/neuedu/digital-scholarship-group/apps/service-requests and can be modified as needed.

For easier tracking of new submissions to Podio app, follow the app by checking the box located in the sidebar below the name of the app and make sure that your account is set to send you email notifications if anything happens in anything you follow (go to My Account > Account Settings > Email & Notifications ).

Currently, the general service request app can accommodate requests for GitHub repositories, server space, training, adding new accounts or users to existing DSG-supported accounts, and changing access levels for these accounts. An "other" option has been left in case of additional service requests.

Email templates may or may not need to be drafted to notify individuals when the DSG has received and/or completed their request and should be specific to the service being provided. New email templates should be added here under an appropriate heading.

Git HubRepositories

GitHub repositories can be requested for current DSG projects using the general service request form. After receiving a request for a GitHub repository, the coordinator should email the person who submitted the request to determine what the repository should be called, if the repository needs to be public or private, and what the individual's GitHub username is so that they can be added to the appropriate Admin team within the DSG's GitHub organizational account. If they do not already have a GitHub account, they can sign up for a free account by visiting https://github.com/.

An email template for responding to requests for new GitHub repositories can be found here.

Setting Up a GitHub Repository

NOTE: The process below has not been tested with an actual project repository yet and may need to be modified. Specifically, it is unclear what privileges admin teams will have and whether or not this is the appropriate level of access. It should, however, be fine if those on admin teams CANNOT create/modify repositories in the NEU-DSG organizational account but CAN add collaborators to their repositories who will then be able to push to and pull from the repository.

Once the DSG has received the name for the new repository, its visibility (public or private), and the username of the first administrator to be added, a member of the DSG can set up the repository, create the admin team for the repository, and add the first admin to the team. All members of the Owners team of the DSG-NEU GitHub organizational account have the ability to create and manage all repositories and teams. Admin levels teams should be made for each DSG project that has a repository. Those who are part of an admin level access team should be able to add collaborators to the repositories associated with their team, but should not be able to create new repositories or change the visibility of their repository. Additionally, all GitHub users can be assigned to as many teams as needed.

  • Create the Repository:
    1. Go to https://github.com/NEU-DSG.
    2. Click the "+ New Repository" button.
    3. Fill out all the necessary fields and then click the "Create Repository" button.
  • Create the Repository Admin Team:
    1. Go to https://github.com/NEU-DSG.
    2. Click the "Create New Team" button in the Teams box on the right.
    3. Name the team (example: reponame-admin) and set the access level to admin and then click the "Create Team" button.
  • Associate the Repository and Admin Team:
    1. Click the "Repositories" tab on the appropriate team page. (All DSG-NEU teams can be viewed at https://github.com/orgs/NEU-DSG/teams/)
    2. Enter the name of the repository you wish to give this team access to and select it from the list that appears.
  • Add Users to the Admin Team:
    1. Click the "Members" tab on the appropriate team page. (All DSG-NEU teams can be viewed at https://github.com/orgs/NEU-DSG/teams/)
    2. Enter the username of the person you wish to add to the team and select them from the list that appears.

Omeka, OJS, and WordPress Installation Requests

The installation request form is located on the DSG website at http://dsg.neu.edu/resources/installation-request/. The app can be found on Podio at https://podio.com/neuedu/digital-scholarship-group/apps/installation-requests and can be modified as needed.

For easier tracking of new submissions to Podio app, follow the app by checking the box located in the sidebar below the name of the app and make sure that your account is set to send you email notifications if anything happens in anything you follow (go to My Account > Account Settings > Email & Notifications ).

Once the DSG becomes aware of an installation request, a task should be assigned through the Podio submission to Karl Yee, who will handle the installation of the new Omeka, OJS, or WordPress instance.

Once the installation has been completed, Karl will typically send a boilerplate email to the site administrator with their login credentials and additional information about their installation and where to get more help. The email template can be found here.

In some cases, additional questions about Omeka, OJS, or WordPress can be forwarded to David DeCamp.

Contact Forms

Two contact forms feed into the DSG primary email account: the DSG contact form and the library digital scholarship contact form.

Tracking Project Progress

We previously discussed collecting information about projects for the purpose of demonstrating outcomes at the DSG to the University. Still need to determine what exactly we want to be collecting information about for this purpose.

Annual Check-in

Process and Goals

We ask all DSG projects to keep in communication with us through several mechanisms. Our DSG Coordinator will reach out at the start of the Fall and Spring semester and attend kickoff meetings as appropriate. In addition, we ask each project to sit down with us for an Annual Check-in, which happens on a rolling basis in April and May of each calendar year. Knowing more about your project helps us in many ways:

  1. We can better assist you in data management and preservation efforts.
  2. We have a better sense of what our projects need when it comes time to make internal decisions about infrastructure and development efforts.
  3. We learn from your project experience, and encourage our other projects to do the same. We want to create a robust community of practice.
  4. We are better able to publicize your project and do outreach on your behalf.
  5. We like to keep our records up to date.

For the Annual Check-in, we will first send you a questionnaire, and then set up a follow-up meeting to go over any questions or issues. After this meeting, we would like projects to write a short paragraph summary of their year for their project website and our website. The DSG Coordinator can help with this.

Systems In Use

Podio: modifications

  • require e-mail address to send copy of form content to
  • Eli will explore how to create this functionality

Interview Questions

  • Please write-up a few paragraphs on your big decisions of the last year, and the intellectual and other contexts of those decisions.
  • What project milestones have you recently reached or anticipate reaching soon?
  • Have any project staff left, or new staff come on board? What contributions did each of your staff make this year?
  • Do you anticipate any new data formats (e.g., map and tiles to render maps)?
  • Have you developed or are you planning to develop any custom code, plug-in, module, visualization, or other tool that requires modifying the standard installation of your CMS and platform?
  • Did you create any new applications, special features, or other interactive modules for your project? Do these new features have preservations implications?
  • Did you start using any new systems or software this year, and if so, why?
  • What upcoming projects or changes or improvement do you plan for the next year?
  • Have you received any media attention or other public notice, or has your project been re-used or cited? We define citation broadly, as both traditional scholarly citation and Twitter, Facebook, and other altmetric re-use. If you've had particular success, please let us know how, so we can share it with other projects.
  • Are there any grants or special funding you've received over the past year?
  • Are there grants or other special funding opportunities for which you plan to apply?
  • Do you have a data management plan? If so, does your data management plan still look applicable to your project, or do you need assistance updating it?

Project Snapshot

Process and Goals

  • The Project Snapshot memorializes and preserves the look and feel of the project at a given time, and is taken before major changes like redesigning the visual layout or moving to a new content management system. It is not a backup copy or an emulation, and is not a substitute for regular backups and versioning.
  • The Snapshot will not capture every piece of the project; rather we will strive to capture "representative" pieces. The Snapshot is not an emulation, which would restore the project it's full interactive state. The snapshot is focused more on file preservation.
  • The three components of the Snapshot are: a writeup of changes, and Archive-It "snapshot", and any custom code (either through a Github release or zip/tar archive.)
  • The snapshot takes place as a benchmark at the start of a project, and before every major milestone with a minimum of once every five years.

Sample Snapshot

Using the ECDA as an example: If they move from Omeka to WP, what snapshot do we want to take?

  • Ask project for a write-up on why you decided to move, including versions of CMS and dependencies (i.e., this is dependent on jQuery or other external things) as well as custom modules, plug-ins, widgets developed for project (i.e., did you use Neatline, write a new WP plug-in, etc.)
  • Take a deep Archive-It crawl of the current site. This will require an initial test run, so budget time for the test run.
  • Capture important aspects that Archive-it does not. This may be any custom Javascript, PHP, and code -- generally, most interactive features of a website. Examples might be: d3 visualizations or project-specific CMS modules. We could recommend GIST at lightweight GitHub alternative for versioning single files.
  • Ask project for a code snapshot, if necessary. If code not versioned on GitHub, but rather on someone's laptop, include as zip or tar file. Package as if for new software release, with any available documentation. We could recommend GIST at lightweight GitHub alternative for versioning single files (i.e., custom d3 or whatever.)

Archive-It questions and comments:

  • The library currently pays for a subscription to Archive-It, with storage and other limits. Requests for new Archive-It projects have implications for subscription costs, or could take up space needed by the Archives.
  • Archives already captures neu.edu and northeastern.edu as deeply as possible, so any DSG projects in those domain are crawled. Projects in outside domains, like viraltexts.org or tapasproject.org, are not. We could request crawls of those domains, but there are implications for storage and other costs.
    • Viral Texts is a good example of project with special considerations: we don't think the main visualization would be captured in a regular Archive-It crawl, much underlying code and data might also need to be preserved outside of Archive-It.
  • How do we get actual data from Archive-It? In other words, could we ask for a zipped version of a website crawl from Archive-It, as a local preservation copy? Michelle Romero (manager of library Archive-It subscription) is checking into this.
  • How does Archive-it preserve dynamic content, if at all? It captures Javascript and all "related files", so can capture some interactivity. The subscription manager can also set a crawl to capture related external files like CSS stylesheets.
  • Anything with interactive pieces hosted elsewhere (Google maps, Vimeo or YouTube) will not be captured. This includes embedded items. The subscription manager can request Archive-It crawl some domains, but files on large domains like Google or Vimeo or YouTube are difficult to parse out.
  • If taking snapshots through Archive-It, assume that a test run is necessary, to verify the system is picking up the desired content. This is the workflow the Archives currently uses.
  • The Archives has a good relationship with Archive-It, and finds Archive-It responsive to questions.
  • Depending on how full a snapshot we want, projects could give us an inventory of other domains (e.g. http://ourmarathon.tumblr.com/) and those could be added to the Archive-It crawl. Again, there are storage and cost implications.

Vagrant comments:

  • Vagrant is a powerful tool for spinning up an entire local server setup, which could be useful in some cases, particularly if a project has a completely customized site (not based on a CMS) or a highly customized version of a CMS such as Tapas. It might not be necessary for some of the more out of the box projects that only use more basic customizations like styling and some plugins/modules.

Setting up a new DSG Employee

General orientation

NB: For full-time professional staff, the first day of employment typically starts with an orientation from NU HR; Dean's Executive Assistant usually chooses the first day based on when that orientation will happen, and registers new employee for that orientation.

  • Before arrival, employee should set up a sponsored account to have computer access on day one. Their permanent computer account can be rolled into this sponsored account.
  • Follow campus checklist
  • Order business cards: send information for approval to Tracey Harik with copy to Library-Supplies@northeastern.edu. Information needed would include name, title, department, "University Libraries", room number, address, email address, phone, fax, and cell phone (include fields as applicable).
  • Make sure they have correct keys, office space; can log into computer; has phone number (set up by Dean's Executive Assistant)
  • Create account, with photo if possible, on library website, to show up in online staff directory
  • Suggest meetings with DSG staff to learn about DSG operations
  • Suggest meetings with library staff in other departments as appropriate (Scholarly Communication, Research & Instruction, RADS, etc.)
  • Take new employee on physical tour of library, stopping by all departments to walk around and introduce in person.
  • Email Karl Yee to add new employees to Library-All and other necessary email lists once they have a campus email address. NB: Library-All requires sponsored email account.
  • Set up lunch with new employee and available members of department in first week or two
  • Give copy of sick and vacation time tracker (typically, obtain from Dean's Executive Assistant)
  • Give copy of most recent division and library goals and strategic plan.
  • Add to staff listing on DSG website
  • Suggest employee subscribes to NU-Digital and BostonDH email lists
  • Set up with accounts on DSG systems -- see Access to DSG Systems list below.

Student Employees

  • When creating jobs
    • The number of hours listed does not matter -- if student can increase from 5 to 15 a week, that's fine. NB: If work-study, since work-study only comes with a limited budget, working more hours per week means running through that budget sooner.
    • If student will be hired in Fall and through Spring, and is paid out of part-time budget, can make end date of hire commencement; do not have to end hire in December and re-hire in January.

Work space

Students are welcome to work in the back right cubicle in the DSG, as well as the common areas. There is a computer there if needed. Students will be given a key to the back office space for access if they are directly employed by the DSG. Students employed by DSG projects can work in the common area outside the offices. The DSG coordinator has their own cubicle.

Time Sheets

The official student deadline for submitting timesheets is Monday at noon. Usually Sarah Connell will approve timesheets, and Amanda Rust is the back-up. Our deadline for approval is Tuesday at noon.

If we happen to see a late timesheet (i.e., submitted after noon on Monday), we will often go in and approve it. But, particularly in the summer with vacation and conference travel, we can’t guarantee we’ll notice and approve anything after Monday at noon.

If you submit a timesheet late, that pay is just included in your next paycheck.

Paychecks are every Friday, for the timesheet submitted the previous week.

For those who are working more than one job on campus, be careful not to fill in the same hours for your different jobs. The system won't warn you if you do this, but instead rejects the timesheet after we've approved it, which can slow things down.

If there are any weeks a student doesn't work, they should dismiss the timesheet, rather than letting it become "delinquent."

Access to DSG systems

  • Podio: Any member can invite them. Create a Podio profile so can be added to appropriate projects.
  • WordPress: one of the administrators needs to create a user account
  • DSG Wiki: Karl needs to create a new MediaWiki account
  • DSG staff listserv: Syd needs to subscribe the person
  • GitHub: any admin can invite them
  • Booking DSC spaces: NUSSO admin in Access Services needs to grant the right permissions
  • SharePoint (Ethan for troubleshooting)
  • Add to Slack (any current Slack member can do this)

URLs

Retrieved from "https://dsg.northeastern.edu/wiki/index.php?title=DSG_Procedures&oldid=3283"