Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Sally = purple

Max = orange

Re-org:

https://docs.google.com/spreadsheets/d/1S5C217M3JUZfHSlLarQjAUqCofJ9jMi_C2VIGvyT8KA/edit?usp=sharing

Github structure: 

Propose creating / maintaining these organizations: 


https://github.com/archivesspace/
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.

Committer Policy: Code in this organization must adhere to x guidelines (test coverage and/or documentation)

Maintained by: Program Team, Core Committers.



https://github.com/archivesspace­plugins/
Purpose: contains plugins officially supported by at least the ArchivesSpace Program Team.
These plugins are tested and updated as necessary to be compatible with new releases.
Provides a focal point to discover plugins and contribute to their development. 

Committer Policy: 

  • Code in this organization must adhere to y guidelines (test coverage and/or documentation). 
  • Approval process to be considered 'official plugin'?


Maintained by: Program Team, Core Committers. (plugin committers?) <--- believe we decided on 8/24 not to have a separate plugin committers group



https://github.com/archivesspace­labs/
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. 


Committer Policy: 

  • This area is open to any contributions and there are no minimum requirements for adding scripts, etc. 
  • Adherence with y coding guidelines and inclusion of some documentation is encouraged but not required. 

(Core committers? Committers Oversight?) will conduct a early review of archivesspacelabs and will move clearly abandoned or obsolete code to deprecated.

Maintained by: Community Committers.


As per the notes from last time, since we're trying to encourage "as much collaboration, sharing and committing as possible," it might be nice to lower barriers if we had some resources readily available from this space. I'm not suggesting we create any, just point to existing guidelines/tutorials on GitHub lingo, getting things in there, best practices for READMEs (even if we aren't requiring any documentation), etc., who to ask for help, etc.



https://github.com/archivesspace­deprecated/
Purpose: contains repositories that should no longer be used with ArchivesSpace or that have
become generally obsolete.

Maintained by: Program Team, Core Committers.





Committer groups:

Program Team: only employees of ArchivesSpace can be part of this group. Access to
everything (admin).

Core Committers: devs with experience of contributing to ArchivesSpace, trusted to review and
merge pull requests etc. Access to everything (admin).

Process / criteria for adding new members: 

A private mailing list for existing code contributors; any existing code contributor can email the list to propose a new member who has submitted at least one PR. The group then votes on the new member - they nearly always get confirmed. The group could see ArchivesSpace adopting a similar mechanism.

  • We'll need to define a process for code review 
  • We'll also want to define 'rights and responsibilities' of core committers that specify good practice such as not merging your own code, etc. <--- Fedora has a good  'rights and responsibilities' doc that we can probably use as a model. 

Oversight for the core committers comes from the Program Team developer(s) and other
established core committers ...
Plugin committers: not sure is needed? Group that can have access to all plugin repos.


Community Committers: Any developer wanting to contribute a project to labs or work within it.
Access to labs (write access).There are no minimum requirements for adding resources to labs. Adherence with y coding guidelines and inclusion of some documentation is encouraged but not required. 

Need to decide how labs will work. Will it be forking external projects or encouraging developers 
to work within it directly and transfer existing projects to it? Former is more hands on and will 
require keeping the forks up to date, latter may be harder to get buy­in (devs can also do both 
quite easily by adding labs as an additional remote ­­ should probably encourage that for devs 
who want to maintain control, but can also push to labs). 


About the forks: would we have to keep forks up-to-date? Could that be part of the yearly review to see if things get deprecated (would that be too much)? I like the idea of encouraging devs to make it a remote.

Process / criteria for adding new members: 

Oversight for the community committers comes from TAC (a new subgroup or the existing
comitters oversight group?). One member of the subgroup will be responsible for adding new
members (should be a committer or promoted to one?). Criteria for new members? Anyone who
requests access?





Committer policies:  

Test coverage and / or documentation requirements. Will differ per org?
Merge policy (i.e. don’t merge your own work ...)

Plugin submission process:

Need to define how to submit a plugin to become official ...

tried to incorporate notes in this section into description of areas and groups above 


Deprecation process:

To deprecate a repository it must first be announced to the mailing list for input. If there are no
objections then the the Program Team Manager should confirm the status. With approval the
repository can be transferred into deprecated two weeks after the initial message.

Minor issues:

Labs branding and making it clear that none of the projects are officially supported.


incorporated this note in plugin section above




Next steps:

  • No labels