On 16 September 2013 15:26, Rob Weir <robw...@apache.org> wrote: > On Mon, Sep 16, 2013 at 8:21 AM, janI <j...@apache.org> wrote: > > > > > > > > On 16 September 2013 14:07, Siva <s...@talentinfotech.com> wrote: > >> > >> Hope I could do this job but have a little expertise with moderation. > >> Probably Listing down what are the jobs to do would be good. > >> > >> > On September 16, 2013 at 7:59 AM Rob Weir <robw...@apache.org> wrote: > >> > > >> > > >> > On Sun, Sep 8, 2013 at 9:42 PM, Rob Weir <robw...@apache.org> wrote: > >> > > I'd like to propose a new mailing list: ad...@openoffice.apache.org > >> > > > >> > > It would serve a few primary purposes: > >> > > > >> > > 1) A focused mailing list to help our volunteer admins coordinate > >> > > maintenance of our project infrastructure, or at least that portion > of > >> > > it maintained by the project. > >> > > > >> > > 2) It would give a single point of contact for admin-related > >> > > questions, outage reports and requests from project members or the > >> > > public. > >> > > > >> > > 3) It would allow other parties interested in monitoring our admin > >> > > discussion, say Infra@ members, to follow a more focused list. > >> > > > >> > > If this idea sounds good, we'd need the usual set of 3 or so > >> > > moderators, geographically disbursed. > >> > > > >> > > >> > The proposal has been out for 8 days now. Mostly +1's, though there > >> > was the suggestion that we wait until there is an organized > >> > admin-team. But then I pointed out that this is not only for > >> > sysadmins, but admins of other systems like Bugzilla, mailing list > >> > admins, as well as being the list for incoming reports from the > >> > public. My impression was that satisfied any concerns. > > > > > >> > >> > >> > To move this forward now I will need some list moderator volunteers > >> > for the new list. If you can help moderate, please respond with your > >> > preferred moderator email address. > >> > > >> > Note: I'd like us to keep the admin on-topic. So if moderators > >> > receive emails asking product support questions, I'd expect them to be > >> > rejected, with a note pointing the user to the forums and/or the user > >> > mailing list. > > > > > > I was one that had a bit of concern, my major concern was the fact that > the > > list would be archived and have quite a number of people (I think there > are > > some 30+ people with admin rights on mwiki). > > > > may I suggest that all issues that can be remotely viewed as security > > relevant: > > - All kind of upgrades > > - All kind of changes login handling (spam filters) > > - All spam discussions > > > > are NOT to be discussed on this list. Discussing these items would be a > red > > carpet for those who want to exploit our servers. > > > > If it makes more sense to have this be a private list, open only to > admins, PMC members, Infra and other Apache Members, then I'm OK with > that. That would ensure a greater degree of security. But it would > require discipline of another kind, i.e., that we don't use it for > general discussions that should be done on the dev list. >
it makes me nervous to discuss vm security themes on a list where all different (BZ; blog, web, mwiki, forum, PMC, infra) admins are part of, and one that is being archived. Infra is a normal public ML, which are used by all committers to forward requests to infra. Infra-private is archived, but only accessible to Apache members and infra-root, which makes it as secure as we can. But even with that limited audience, we (infra) never discuss real security issues there and upgrades are only discussed briefly. In my mind, the themes I list above, should only be distributed to those who are actually involved in the particular items e.g. - A mwiki login change, is only discussed among the mwiki-sysadmins. - A forum upgrade (with security patches) is only discussed among the vm-sysadmins for that vm. - Security patches (like the one issued for mwiki) is not discussed at but deployed (or not) by the 1-2 persons actually doing the job. After deployment we dont inform that it is deployed, simply because it would tell people where it is not deployed. Lowering the security bar is calling for trouble also if its just done on an information level. rgds jan I. > > -Rob > > > rgds > > jan I. > > > >> > > >> > Regards, > >> > > >> > -Rob > >> > > >> > > >> > > >> > > Regards, > >> > > > >> > > -Rob > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > > >> ---------------------------------- > >> Thank you very much for your time. > >> ---------------------------------- > >> Siv, > >> Acquisition Coordinator, > >> Talent Infotech Inc, > >> 304 Canterbury Way, > >> Severna Park, MD 21146. > >> ======================= > >> Phone: 443-722-2543. > >> Fax: 425-696-9020. > >> ---------------------------------- > > > > >
