Rob Weir wrote on Sun, Sep 08, 2013 at 18:11:19 -0400: > On Sun, Sep 8, 2013 at 5:40 PM, Andrea Pescetti <pesce...@apache.org> wrote: > > On 04/09/2013 Rob Weir wrote: > >> > >> On Wed, Sep 4, 2013 at 12:36 PM, janI wrote: > >> > >> I assume we want well-maintained servers that help us get our > >> project-related tasks done, and also help serve our users. > > > > > > Yes we do. And Jan's proposal seems very reasonable and dictated from > > experience (both personal experience and the experience of actually > > maintaining these servers). > > > > > >>> some thoughts on how admins could work, but in general I > >>> believe we should convince infra to take over the vm responsibility and > >>> keep our well functioning forum/wiki admins. > > > > > > Last time we approached Infra on this, their answer was: find resources > > (people) within the OpenOffice project to take care of the non-standard > > tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe they > > helped a bit respecting these lines so far. > > > > Handing over to Infra would indeed be "peace of mind" for us, but I still > > think that your proposal makes sense in light of the above: Infra prefers > > that project-specific tools are maintained by the project itself as a > > first/primary contact, and escalate to Infra if needed. > > > > By the way, if you believe that Infra could now be available to support us > > more closely, feel free to investigate. > > > > > >> maybe > >> 3b) Try to evolve systems so users can implement their own wishes, in > >> a way compatible with 1) and 2). For example, if routine logos and > >> footers are synched to resources in the project's SVN tree, then any > >> committer can update things. > > > > > > This is not feasible in the current state. Even ignoring the fact that this > > issue derailed the discussion, I see no benefit in implementing this: if we > > have a real (reasonable active) team maintaining the servers, and the team > > is not a bottleneck for the community, we will be fine with it. I won't feel > > "excluded" if I have to ask someone to change some configuration: this > > routinely happens for Infra-maintained services, or for our Bugzilla, and it > > works. > > > > That does not match my experience at all. From trying to get the > terms and conditions statement on the Forum to integrating Google > Analytic across the websites to rolling out the new logo, my > experience has been that getting simple content changes make to the > VMs has been very frustrating. Some of these changes took months. > > (Note: I'm not talking about "configuration". I'm talking about > website content, things like logos, contact information, terms and > conditions, copyright statements, etc.) > > You say that if we had active admin teams maintaining the servers, > this would be easier. But we don't have such a team So these changes > have been painful. Considering the admins are scarce and their time > is precious, I'd like to find ways that we can allow some degree of > "self- service" for committers, so we don't waste admin time on > trivial content changes. Have the admins focus on things that only > they can do. >
I'd also like to point out that allowing any committer to make changes --- when that is easy to implement, does not raise security or privacy issues, and does not lead to abuse --- makes the project more inclusionary, which is a good thing. It's not unlike enabling non-committers to review patches. Daniel > So this is not an either/or question. We should both have an active > admin team as well as move toward allowing committers to maintain the > content of our websites. > > Regards, > > -Rob > > > > >>> A good setup would be, 3 types of admin: > >>> Each server will have an appointed "owner" (anchor-admin) > >>> A number of persons have full sudo on a server (admin) > >>> A number of persons can reboot/restart/work on po files (help-admin) > > > > > > Something that we might discuss (but I guess this is implicit in your > > proposal) is to avoid that the same person is the "anchor-admin" (or > > "contact-admin", i.e., the first point of contact) for all the three > > machines. This might help in sharing the knowledge and mitigate the > > "loneliness" you have experienced so far in maintaining our infrastructure. > > > > It would actually make a lot of sense that you continue to be the > > "main/anchor-admin" for at least one of the machines, so that the other > > machines can be smoothly transitioned and that the whole knowledge, not only > > what's written in the documentation, can be shared. > > > > Regards, > > Andrea. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
