Hi Daniel, > Can you comment on what this means from a technical perspective?
I will comment with our thinking at the moment, but happy to hear thoughts and ideas, as this is something we're just starting to experiment with. > Does autonomy mean that volunteers will be able to pick any arbitrary > version of an application and start running it on FSFE hardware? I would leave the decision of which version of a particular application to run up to the volunteers who run the service, as they would be the ones who know the software best. When someone wants to start a team to run a particular service, however, our principal system administrators team will need to approve this. Over time, I imagine us developing some more rigid guidelines for this, but so far I've only started sketching out the very basics here: http://wiki.fsfe.org/TechDocs/FellowRunServices > Or will > volunteers run it on their own hardware and if so, how will things like > authentication credentials be shared? We expect everything to run on our own hardware, which is a pre-requisite for our current authentication scheme. At the moment, services would authenticate via our LDAP, but we expect to deprecate this soon in favor of either (1) an openID connector, or (2) individual passwords for the respective services. > I often come across people who insist that they have to run the latest > version of something from Git, usually with a hodge-podge of > dependencies downloaded directly from different web sites. These types > of arrangements are often very unique and very hard to support when the > person is on holiday or decides to stop supporting it. I agree, but I would be okay with supporting this, if the team agrees this is the way they want to run the servie. It's important to note, I believe, that all services provided in this way -- and indeed, most work of the FSFE -- is done in teams, with a one coordinator and a deputy coordinator. We should not get into the situation where we have a single person responsible for a service, and indeed, building a single point of failure in that way doesn't contribute to the learning which we would expect either. So if we get to the point where there is no interest beyond one individual to run the service, it would likely be better to not run the service at all. And perhaps this ought to go in our guidelines: each team should, for their service, clearly document the steps needed to be taken to shut down the service (including exporting data to the individuals, sending out shut down messages, etc). Sincerely, -- Jonas Öberg, Executive Director Free Software Foundation Europe | [email protected] Your donation enables our work (fsfe.org/donate) _______________________________________________ Discussion mailing list [email protected] https://mail.fsfeurope.org/mailman/listinfo/discussion
