On Thu, Mar 7, 2013 at 10:33 AM, janI <[email protected]> wrote: > On 7 March 2013 15:55, Rob Weir <[email protected]> wrote: > >> On Thu, Mar 7, 2013 at 8:56 AM, janI <[email protected]> wrote: >> > On 7 March 2013 09:53, Andrea Pescetti <[email protected]> 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. >> > >> >> But please note that I never suggested moving off of MWiki. >> >> > >> >> >> >> 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. >> > >> >> This is what I see: >> >> 1) We brought over MWiki and had a single person (Terry) who really >> knew what was going on. We may have had others who had permissions, >> but they were not (IMHO) able to keep the wiki stable. >> >> 2) Terry left, and the wiki was not maintained as well. Eventually it >> fell due to massive spam. No one of the existing admins stepped up to >> fix the problem. Whether this was from skill, permissions, time, >> inclination, I don't know and I don't judge. But the actions were to >> disable new account creation and treat that as a new way of life. >> >> 3) You stepped up and took the lead on getting MWiki to be properly >> maintained again. If you had not done that I am pretty sure that we >> would not have the ability for new years to create accounts today. We >> were already down on one knee when you offered to help. I'm pretty >> sure without your help things would continue to degrade. >> >> 4) So what would things look like without you? Sure we have others >> who have some permissions. But is that enough? (It wasn't enough >> before). What do we need to do so we are not dependent on a single >> person? Not just from a theoretical standpoint (X and Y have >> permissions) but from a practical skill and knowledge level as well. >> > > I think there are too much focus on the sysadmin part, which isnt really a > problem..mwiki is very stable, it needs an upgrade now and then (2 times a > year in average). Our httpd, ats, firewall, ubuntu needs a lot more regular > maintenance, and thats where people like rjung and gmcdonald are of great > help. >
This was one bullet item among 11 concerns I raised. I don't think a fair read of the page would lead anyone to think that this is "too much focus" on this topic. > I know "sidestepping". I can see your point of having multiple active > skilled persons on the team (even though I dont agree with it), but getting > more volunteers without the skills/motivation is simply not helping ! > Before I jumped in there has been plenty of time for other volunteers to > step up alongside with the 2 who already have access. If someone comes > along today, I will happily tell them how the current setup (and now it is > even documented in svn). > > As I wrote I respect whatever decision is made, but please also respect my > wish. I do want to use my limited time to bring our community forward and > not discussing, which is going to happen with a larger number of sysadmins. > > >> >> 5) Note the same applies to phpBB as well. >> >> From a high-level perspective, one way is to think of it like this: >> As a large project with diverse technical infrastructure we make high >> demands on Infra, hardware, bandwidth, sys admin time, etc. Since we >> have such a dependency on this technical infrastructure, more so than >> other Apache projects which are less end-user facing, this starts us >> off with greater risks. Our use of non-standard services like MWiki >> and phpBB increases the risk. Fine. So how do we balance those risks? >> > > Simple answer is "we dont", we have the people, we have the needed help > from infra. I stepped in when needed, when I am not around another person > steps in. > > I wish we had the same attention on our the software...how many people do > we have the really understands the build procedure or for that matter the > l10n process ? How do we handle a situation deep in the software. I think > the support for our software is pretty much like mwiki, in many cases only > 0 or 1 who knows the code, and a couple who knows in generally. > You, or anyone else, is welcome to start a page on L10n process or development. Otherwise I'll get around to it eventually. As you say, there may be similar issues in these areas as well. We should be honest about where the risks are. -Rob > But I agree in a strategy paper anything can be written, and if our main > focus shall be on non-essential parts like mwiki etc. so be it. > > rgds > Jan I. > > >> > 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. >> > >> >> These are not mutually exclusive options. One of the luxuries of a >> strategic plan is I can suggest more than one priority. >> >> Regards, >> >> -Rob >> >> > rgds >> > Jan I. >> > >> > >> > >> > >> > >> >> >> >> Regards, >> >> Andrea. >> >> >> >> >> >> >> ------------------------------**------------------------------**--------- >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org< >> [email protected]> >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
