On 3/7/13 2:56 PM, janI wrote: > On 7 March 2013 09:53, Andrea Pescetti <pesce...@apache.org> wrote: > >> Rob Weir wrote: >> >>> On Wed, Mar 6, 2013 at 5:46 PM, Kay Schenk wrote: >>> >>>> "Sustainability concerns due to our use of unsupported applications (from >>>> Apache Infra perspective), including phpBB and MWiki and reliance on a >>>> very >>>> small number of system admins." ... >>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/** >>>> Website+Strategic+Plan<https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan> >>>> >>> And let's not forget alternative ways of addressing this concern: >>> 1) Work with Infra to make MWiki be officially supported. >>> or >>> 2) Form our own admin group >>> >> >> Indeed, I see no reasons to revisit, especially at the current stage, the >> MWiki vs [any other wiki] issue. >> >> MWiki is the biggest source of information about the project; while its >> content is often outdated, it's still very useful. Existing links to the >> MWiki pages are in the thousands (or more). It has been updated with a huge >> effort lead by Jan, and it is now stable and reliable. >> > > I totally agree with this point of view, but when a PMC raises doubt about > using Mwiki, it is something we all have to listen carefully to, afterall > one of the points in being PMC is to secure the long term stability of the > community and product. > > This is also the reason I researched cwiki and moin...not that I personally > would like to change, but because I read the mail from one PMC and the > reactions from others. > > >> >> If our problem is to enlarge the administrators group for MWiki or to get >> it officially supported, I prefer to explore these options first. We >> already have three committers who can administer MWiki on the system >> administration (shell access) side, right? (jani, imacat, rbircher). How >> many more do we need? I've also just asked Infra for clarifications about >> the "supported applications" issue. >> > > At the moment we have no-one with "just" shell access, all 3 have (or can > have) root access. Furthermore rjung (infra) pratically maintains httpd, > gmcdonald (infra-root) helps with more or less everything and Clayton helps > with mwiki setup (without access). BIG Thanks to all three for their great > help ! > > After the upgrade we have had one incident (which rjung handled), one > upgrade proposition (which I handled wrong) and 2 request for change (one > pending and one I have handled). At the same time, nothing have been done > "inside" mwiki regarding old pages, strange categories, spammed paged, > misleading information. > > At the moment 2/3 of the time I use on mwiki goes to logistic and > coordinating people, if the group is expanded my experience is that the > overhead grows exponentially. I respect the wish of the community and when > the group is expanded, I will withdraw (after a handover), I am here to get > things done and not to coordinate people. > > I fully understand we need many sysop, and the idea of having a mail list > (or just a wiki-page, with sysop access level) is a good idea. Our biggest > job at the moment is not sys-admin but normal sysop work.
I think we mainly need admins with the skills to do the maintenance work. Jan have shown his expertise and drove things forward and helped with critical issues like the spam attack. If somebody volunteer to help out here it is important to be committed to do the job in some way. It doesn't help us to have a list of admins where only one is active. It's no problem if priorities are changing over time but it have to be communicated. And if the skills are not present I would expect that the volunteer is willing to learn from the other sysops over time to build the necessary skills. We should also think about some kind of knowledge base where we document related things that are specific to our installation etc. > > I honestly think we should consider more how to stabilize the "inside" of > mwiki instead of focussing on the sysadmin part, but that is just my > opinion. I think it's probably a combination of both. The group of admins can leverage each other to build the knowledge and work together on a stable and secure setup. Juergen > > rgds > Jan I. > > > > > >> >> Regards, >> Andrea. >> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> dev-unsubscribe@openoffice.**apache.org<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
