Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Service Agreement between ProgHist Ltd and Existing Publications #1704

Closed
acrymble opened this issue Mar 8, 2020 · 20 comments
Closed

Service Agreement between ProgHist Ltd and Existing Publications #1704

acrymble opened this issue Mar 8, 2020 · 20 comments
Assignees
Labels

Comments

@acrymble
Copy link

acrymble commented Mar 8, 2020

Related to #1703 (Service Agreement between ProgHist Ltd and New Publications) and #1685 (Identity - Journal vs Website), we could benefit substantially from clarifying the responsibilities of ProgHist Ltd towards its publication teams. I'd like to propose a service agreement to be collectively drafted by all teams to outline those responsibilities (and limits). That should clarify the relationship and ensure in writing the editorial independence of the publications.

I will start a Google Doc and share it with everyone, and we can work towards something everyone is happy with. I will do this privately in the first instance.

This will have to be something that all teams are happy with, and that is approved by the Project Team, each Publication, and the ProgHist Ltd Board.

@acrymble acrymble self-assigned this Mar 8, 2020
@acrymble
Copy link
Author

acrymble commented Mar 8, 2020

I have drafted a document and sent it via email to all team leaders (whom I've asked to share it with their teams for comment). Can team leaders please tick off here to confirm receipt:

If I missed anyone (sorry) please let me know

@acrymble
Copy link
Author

This is an issue on the agenda tomorrow so please make sure you've had a chance to read and share this with your teams @jenniferisasi @spapastamkou @rivaquiroga

@acrymble
Copy link
Author

acrymble commented Apr 2, 2020

Thank you everyone for your comments on this draft. I'd like to know if the document (in its current form) is ready to go to a vote at our next Project Team meeting. Can you please re-read it and if you are happy for it to go to a vote, please check off beside your name. This does not mean you necessarily approve it. It just lets us shift it into the meeting for a more formal discussion, and gives me a sense of who feels they've had a chance to consider it.

Further comments on the document are of course welcome. I will re-send the link via email to everyone.

YES I AM HAPPY FOR THIS DOCUMENT TO GO TO A VOTE AT OUR PROJECT MEETING:

@acrymble
Copy link
Author

acrymble commented Apr 9, 2020

Thanks everyone. We've passed a 50% threshold of approval to put this on the agenda (not the same as approving adopting it). I still welcome comments from anyone who hasn't yet responded, but we'll mark this as agreed that we'll take it to a vote with the aim of implementing it after the AGM on May 28.

@drjwbaker
Copy link
Member

@acrymble Re your comments in the call, the spirit of the agreement was to clarify the 'services' the Ltd provides to the project, and the responsibilities of the project in turn. I agree that what we have can't be signed by the Ltd. But it strikes me that by moving some of what we have from Ltd responsibility to Publication Team responsibility, or editing the Ltd responsibility, we get a useful document.

E.g.

Edit..

Providing and maintaining a publishing platform for the journal that is fit for purpose.

.. to something around the role of the Ltd in supporting reasonable financial costs incurred to run a publishing platform.

Or moving..

Archiving a copy of the journal annually in an appropriate repository as determined by the publisher.

..to be a responsibility of the Publication Team.

Does this make sense?

@drjwbaker
Copy link
Member

@acrymble: if you want, I can take a stab at this (with suggested edits).

@acrymble
Copy link
Author

My understanding of the agreement was to clarify for publications what the 'publisher' provides and what it expects in return. The publisher is only nominally ProgHist ltd. In practice it's the Project Team board.

I think the easiest way forward is just to have team leaders the signees, and maybe clarify that 'ProgHist ltd' is the shell that effectively holds ownership of everything to be used as directed by the project board, rather than suggesting it's the publisher in practice.

@drjwbaker
Copy link
Member

drjwbaker commented May 26, 2020

Do we need agreements in writing between sub-teams? (which is more or less what you are proposing) I can see the rationale for one between a company (shell or otherwise) and a project. But between sub-teams feels like slight admin overkill?

@acrymble
Copy link
Author

acrymble commented May 26, 2020

I can't sign what we've got at the moment because ProgHist doesn't have the ability to guarantee those services. So if you want to rewrite it we can open the discussion again.

Update: this doesn't actually need to be a signed document if it's just a memorandum of understanding between the subteams involved in providing services (the publisher / the project team) and the individual publications. We can just make it 'policy'. I think it's valuable to have that. Especially so that new publications know exactly what to expect, as do we all.

Then we can think about signing something between ProgHist ltd and the Project Team instead. I just don't want ProgHist ltd legally liable for something it can't guarantee.

@drjwbaker
Copy link
Member

I can't sign what we've got at the moment because ProgHist doesn't have the ability to guarantee those services. So if you want to rewrite it we can open the discussion again.

Update: this doesn't actually need to be a signed document if it's just a memorandum of understanding between the subteams involved in providing services (the publisher / the project team) and the individual publications. We can just make it 'policy'. I think it's valuable to have that. Especially so that new publications know exactly what to expect, as do we all.

Then we can think about signing something between ProgHist ltd and the Project Team instead. I just don't want ProgHist ltd legally liable for something it can't guarantee.

I totally agree. There are some things the Ltd should be able to guarantee, not least as it has spending powers. Let me have a go at suggesting what there might be on the doc (I suggest you make a copy if you want to use it hsa the basis for the memo between teams).

@drjwbaker
Copy link
Member

drjwbaker commented May 26, 2020

@acrymble I've gone through this and it is largely compatible with a Ltd <-> Publication agreement.

@acrymble
Copy link
Author

@drjwbaker I think some confusion has crept in here as to the purpose of this agreement, and I think we're trying to make it do 2 things. I think I've also forgotten along the way, which hasn't made this easier.

This document was originally created to provide a very clear agreement between the publisher and publications, and was crafted in particular with the Portuguese team in mind, who it wasn't clear were understanding the nature of the relationship they were entering with us.

In particular, that they agreed, in accepting lots of free time and effort and services on our part, not to leave with the journal or to do things that would let it fail/damage our reputation/otherwise bad stuff. Since the Programming Historian Project Team is not a legal entity, the agreement places ownership of the journal we're creating with ProgHist ltd so that we can actually ensure the legal protections and rights we've got built into the business.

In exchange for giving up those rights, we would also bind ourselves to provide what they needed to be successful.

I think we need to untangle a few bits that are crafted with the idea that this is more about ProgHist than it really should be.

Am I reading that right?

@drjwbaker
Copy link
Member

@drjwbaker I think some confusion has crept in here as to the purpose of this agreement, and I think we're trying to make it do 2 things. I think I've also forgotten along the way, which hasn't made this easier.

Okay. I agree that this got muddied. Apologies if I added to the confusion, I guess I was working with my Ltd hat on.

Perhaps I should take a step back and let you unmuddy the purposes of this, then come back in if their are specific Ltd related matters to attend to?

@acrymble
Copy link
Author

acrymble commented Jun 1, 2020

Sure @drjwbaker I will try to do that this week. I think it's actually only a few minor little tweaks. We can then re-circulate it for everyone to check.

@acrymble
Copy link
Author

acrymble commented Jun 9, 2020

I've finished editing this and I've sent it to team leaders to check if anyone has any remaining comments. Hopefully we can all sign at the next Project Team meeting.

Update: just keeping track of who I've heard back from so far in case I need to follow up (@JMParr @jenniferisasi @acrymble @svmelton @DanielAlvesLABDH @ZoeLeBlanc @spapastamkou )

@drjwbaker
Copy link
Member

Thanks Adam.

@DanielAlvesLABDH
Copy link
Contributor

@acrymble I think I never got access to the Google Docs you mention about the Service Agreement. What is the ststus of this and what do you need from from me?

@acrymble
Copy link
Author

Update:

All teams have approved this agreement except the @programminghistorian/spanish-team who I have not yet heard from.

I'm going to suggest we take the agreement as accepted for 3/4 of the publications and all of the 'publisher' teams (Global, ProgHist, Comms, Tech). And that we move to approve this at the meeting #1871 and close this issue.

@acrymble
Copy link
Author

I've now heard from all teams. I'll file a copy of the agreement with our archivist and put the text on the Wiki and then close this ticket.

Thanks everyone.

@acrymble
Copy link
Author

This is now complete and approved by all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants