Versions Compared

Old Version 34

changes.mady.by.user Esmé Cowles (Unlicensed)

Saved on

compared with

New Version 35

changes.mady.by.user Sally Vermaaten (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Sally = purple

...

___________________________________________________________________________________________________________________________________________________

https://github.com/archivesspace/ - discussed 10/24/2016 & 11/7/2016

Purpose

Contains the core ArchivesSpace repositories, including the main project and migration tools. All code here is officially supported and maintained by at least the ArchivesSpace Program Team.

...

ArchivesSpace is open source and released under ECL, v 2.0. The software and associated documentation is developed collectively by a community of contributors and committers. All interested community members are encouraged to contribute to the project. Contributors who demonstrate sustained engagement with the project through quality participation in meetings, mailing lists, documentation and code updates can be nominated by existing committers to also become a committers. It should be emphasized that committers need not be limited to software developers. Community members with skills in documentation and testing, for example, can also be committers. (should we consider program staff a separate group?)

Rights

Committers share the following rights:

...

ArchivesSpace Committers Calls are a monthly meeting re monthly meetings of the developers of ArchivesSpace, who discuss modifications and innovations in the code, and review new and open tickets.  Calls are open to interested

Process for Adding a New Committer Process

This section describes the process for handling the voting of a new committer. Voting is handled by emailing the Committer List.

Summary:

    1. Call a vote (insert link to template here - similar to templates/committerVote.txt)
    2. Close a vote (insert link to template here - similar to templates/closeCommitterVote.txt)
    3. Invite the new committer (insert link to template here - similar to templates/committerInvite.txt)

If they accept, then do:

    1. Add to Committer team of GitHub ArchivesSpace archivesspace organization
    2. Add to Committer team of GitHub ArchivesSpacearchivesspace-Labs labs organization
    3. Add to archivesspace-committers google-group, group used nearly exclusively for this voting process
    4. Add to committers wiki page: ArchivesSpace Committers
    5. Announce the new committer (insert link to template here - similar to template/committerAnnounce.txt)

...

  1. Make sure that you have completed an Individual Contributor License Agreement, or that your institution has completed an Corporate Contributor License Agreement.

  2. Find or create a bug report or feature request ticket in JIRA GitHub (to make sure you’re not duplicating work and document the intent of your contribution). It helps to explain both the existing behavior and the desired behavior that your change will implement.

  3. Set up a GitHub account if you have not done so before.

  4. Fork the ArchivesSpace repository on GitHub.

  5. Create a feature branch.

  6. Make changes in your fork. We advise contributors to follow these guidelines to expedite the contribution review process.

    1. Follow established style guidelines

      1. Rails: https://github.com/bbatsov/rails-style-guide

      2. JRuby: https://github.com/jruby/jruby/wiki/JRubyStyleGuide

      3. RSpec: http://betterspecs.org/

    2. Include unit tests sufficient to cover the feature(s) you add or bug(s) you fix, and make sure the test suite passes. (Can we rely upon Travis or a Jenkins instance for this, or should we suggest that contributors run tests locally?)

    3. If you’re adding a feature or otherwise changing documented behavior, modify the documentation to reflect your changes.

  7. Once your work is done, squash the commits in your branch — see One Commit per Pull Request for some guidelines — and rebase it on the latest in the upstream master branch. We appreciate succinct but explanatory commit messages.

  8. Push your updated branch to your fork.

  9. Create a Pull Request on GitHub.

  10. Respond to feedback as the community reviews your contribution.

...

  • For starters - get a starter group 5 -6 people
  • Page with these are the committers
  • Github - links to email addresses, etc.
  • Rights 
  • What we need: 
    •  Describe core committer nominations process 
    •  Define rights & responsibilities
      •  include guideline that you get your employer's blessing?
    •  In Github page describe who people are w/ links to who core committers are & what their communication process is - e.g. development meetings (e.g. biweekly or monthly) - Hydra & Fedora have weekly - for ?s, work underway - e.g. release; i want to make this big change, should I wait or is that cool?; also a good place to just get updates on technical progress of project (e.g. this is a useful-looking page: http://islandora.org/developers)


Sally's thoughts on structuring this documentation from looking at other OSS community examples:


___________________________________________________________________________________________________________________________________________________

...

___________________________________________________________________________________________________________________________________________________

https://github.com/archivesspace­labs/ - discussed 10/24/2016

I wrote something up here: https://docs.google.com/document/d/1a_4AEgXHHZnbKWwjRcEVw8FWdme1cldKWvII9cLRYxI/edit?usp=sharing

Purpose: contains proof of concepts, examples and experimental projects. There is no official
support from the Program Team for anything in labs. The projects are not guaranteed to be up
to date with the latest release and are used on a at­your­own­risk basis. Program Team and
other “official” committers can contribute to labs but that does not confer official support to any
project. Note - Labs branding should make it clear that none of the projects are officially supported. 

...

ReviewActions from previous calls:

  •  ACTION - Code in this organization must adhere to x guidelines (test coverage and/or documentation) - cleaning up text - Sally - with group to review afterwards; 
    • Codifying existing practices
    • Test coverage; passing test


Actions from November 7th, 2016 call: 

  •  Create separate 'clean' doc?



Overall Plan: