-
Notifications
You must be signed in to change notification settings - Fork 229
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
Approval process for new teams #1718
Comments
I suggested in 2020-03-23 project team meeting that it may be worth assigning a point-person from @programminghistorian/technical-team to be the first point of contact for when there are technical issues uploading new files and pages. I will follow up at our next tech team meeting. |
Per @acrymble suggestion, I will be the point person for the new Portuguese Team that will be joining us. He's already put me in touch with the managing editor and added me to the relevant tickets. As we move forward I'll make some suggestions as to how to define the role. @mdlincoln If it's possible, could I be included in this upcoming technical team meeting? |
@JoshuaGOB yes I will make a note to include you - I will be creating a Doodle poll after the end of this call |
From a @programminghistorian/communication-team perspective, specially Newsletter and Tweets, the addition of a new team involves +1 language on everything, thus, I suggest something like:
I anticipate that at some point the Communication Manager will not be fluent in all the PH languages, so the above roles would be necessary. (It will be a while until the PT team joins and, provided that I am not working too much in other issues, I can do the initial translations to PT like I do with FR, but if I'm busy...) |
@jenniferisasi I think this is an important point to recognize. It suggests to me that the following positions need to be able to support that new team (whoever they are):
Anyone else? Do we want a system that MEs get involved in on behalf of their own publication team? Or is that unnecessary? |
Main financial impact here are with regards to copyediting and our technical infrastructure. On the former, at the moment we commit to:
Our third Patreon goal "will allow us to support the translation of every lesson into English, Spanish, and French". Presumably we need to add PO here, but regardless I suspect we should copyedit every new article we publish, regardless of how many publications we support. This could be tricky if we grow any more. On our technical infrastructure, we have paid twice (I think) for Netlify after breaking out of our free limit. I presume (right, @mdlincoln?) that increasing the number of articles we publish + keeping pages synced across more languages will trigger more payments. Also small side note: the payment is a bit of a faff to administer (I pay then have to claim back from the company, which isn't ideal). I don't know if there are other free services for which we are close to a limit, but it would be worth checking with @programminghistorian/technical-team. |
Thanks @drjwbaker. So if we were to conservatively estimate 1 article per month, we're looking at the cost of a new publication being in the range of £1000 per year in direct costs. That will have to be costed and approved in future if we bring in new teams. |
I currently budget £600 per annum, but with territorial fluctuations £1k might be more sensible. |
I've added this to our May 2020 project team agenda for comment from any stakeholders. If you think new publications affect the workload of you or your team, please consider what support or assurances need to be in place to cover that work. |
A lot of work (particularly technical) has made this easier moving forward. However, we agreed at the May 2020 Project Team meeting that new publications are great for the project but require a huge effort across all teams. Agreed that the remit for new publications falls with the @programminghistorian/global-team but that all team leaders must sign off that their team can commit the necessary resources before any new publications are approved. This does not affect the Portuguese publication but will affect all future publications. To action this, @acrymble and @mariajoafana will contact the @programminghistorian/global-team to make sure they have the support they need moving forward. |
We need an agreed approval process for new teams that goes beyond an agreement with them, but which also robustly tests that the team is ready and capable, that OUR team has the capacity to support them, and that the new publication will serve a legitimate need within the wider community.
Most recently this decision has rested with the Global team, but I'd like to suggest that all new publications must be first discussed at a project team meeting, and approved by the ProgHist Ltd board and the technical team.
I raise this because so far the job of bringing the Portuguese team to fruition has fallen disproportionately on me.
Open Library of the Humanities uses a voting system amongst library partners, since ultimately it's them that pay the bills. I don't think we should go that way, but it is one model out there.
The text was updated successfully, but these errors were encountered: