On Sun, Jul 28, 2013 at 11:43 AM, janI <j...@apache.org> wrote:
> On 28 July 2013 14:31, Rob Weir <robw...@apache.org> wrote:
>
>> On Sun, Jul 28, 2013 at 5:26 AM, janI <j...@apache.org> wrote:
>> > On 28 July 2013 09:01, Andrea Pescetti <pesce...@apache.org> wrote:
>> >
>> >> Rob Weir wrote:
>> >>
>> >>> Note that we do have this page already:
>> >>> http://openoffice.apache.org/**pmc-faqs.html#moderator<
>> http://openoffice.apache.org/pmc-faqs.html#moderator>
>> >>> Maybe that can be updated?  Or if you have something more ambitious in
>> >>> mind, the existing page can be retired.
>> >>>
>> >>
>> >> It will be just fine to update that page.
>> >>
>> >
>> > that page is very outdated, and it is a mixture of all kinds of
>> > information. I think it would be better to have a special page,
>> >
>> > I think pmc-faq, should have exact that content.
>> >
>> > objections ?
>> >
>>
>> An outdated page versus a page that doesn't exist yet?   I guess I
>> don't care, so long as in the end there is a single place to go for
>> this info.
>>
>
> Well I could say the same, a page only a few knows that contains quite a
> lot of diifferent information, and where the maintenance part is outdated
> (doesnt even contain the services we offer), or a new page with the sole
> purpose of information who is doing the job.
>
>
>> >
>> >
>> >
>> >> Additional contact information, if desired, can be stored in the private
>> >> (PMC members only) SVN repository for this PMC:
>> >> svn checkout https://svn.apache.org/repos/**private/pmc/openoffice<
>> https://svn.apache.org/repos/private/pmc/openoffice>
>> >>
>> >
>> > That is a possibility, do you think of telephone numbers etc, for
>> emergency
>> > situations ?
>> >
>> > I will make a proposal on ~jani and ask for lazy consensus.
>> >
>> > Does any maintainer (sysadm, sysop, root etc) have a problem that the
>> page
>> > contain our apache emails ?
>> > If so please object now, before I show my proposal.
>> >
>>
>> We should be using existing tools like the mailing list and BZ and IRC
>> for admin requests and reporting outages.  I don't think we want to
>> encourage direct emails.
>>
>
> hmm, if thats the case then there are no purpose of telling who is doing
> the job...then we all just scream help on whatever list and hope the right
> person reads its. On the other hand, if we want to identify the people
> doing the job I have only found the mailId as a common dominator, if you
> have another id then please tell me.
>

I don't recall ever seeing the mailing list down.  So that seems to be
a solid solution. It has the advantage that we can check email from
any device from any location.

> Using BZ for outages, would be at least interesting, on a good day it would
> take 2-3 weeks before I became aware of the problem. I think for outages BZ
> is not really the suited. IRC might be suited, but I seldom see people who
> can do something in there. Maybe I am just negative, but at least I have
> nearly a full year experience with AOO (and 25+ with other systems) and all
> ourages an until today I have not received a single outage request from BZ
> or IRC.
>
>
>> The real goal, IMHO, should be making sure that the responsible party
>> can easily find out what issues/requests are related to their area.
>> This could be done by using the dev list for all such requests.  It
>> could also be done by having BZ areas for such requests, something we
>> do have today in most cases.
>>
>
> I honestly think that the responsible party know what their area are, I
> think it is more important the informing part knows where to inform.
>
> I take your word for using BZ and dev@, since it saves me the work of
> making a list. But bear in mind that I (as an example) from time to time
> only read dev mail with 72 hours interval, do you really want to wait that
> long to get a server restarted ?
>
>
>>
>> So I would recommend just listing names or Apache ID's (robweir, etc.)
>> without mailto: hyperlinks, for reference.
>>
>
> now you confuse me, you have just argued to use BZ and dev list, so no need
> for specific names ?
>


Sorry for the confusion. I'm suggesting listing names, but not email
address.  The idea is to not make it trivial for someone to click and
send an email.  Remember, we're still dealing with the masses who are
looking for the easy way to technical support. As BZ admin I receive
quite a few product support questions sent to the admin address.
Ditto to the list help address.  So make it sufficient for project
members to know who owns the area, but not so simple that any random
person will use it.

Remember, in many areas we have more than one authorized person who
can fix things.  But we also all take vacations.  Sending an outage
message to personal email has two problems:

1) It does not let others on the dev list know about the outage or
that it has already been reported. This leads to a cascade of more
notifications sent, to the general annoyance of everyone.

2) If the person notified is not available, due to vacation or
whatever, the fix is delayed even further.

So I recommend sending all such issues to BZ if it is not urgent or to
the dev list if it is urgent.  Sometimes I'll even put the dev list
and the person both into the address list if it is urgent, hoping to
escape some level of auto-filing in the mail clients.

Another approach would be to create an ad...@openoffice.apache.org
mailing list for such things.  If all admins subscribed to that list
it would be equally efficient.

Regards,

-Rob


>
>>
>> Of course, every rule has exceptions.
>>
>> Maybe a variation on this approach would work for us as well?
>>
>> http://www.apache.org/dev/infra-contact#how
>>
>
> that was my basic idea, but the difference is that #asfinfra and infra@ are
> solely for maintenance and not for general development (infra-dev@ is for
> that purpose), dev@ is of course mainly related to non-maintenance issues,
> and as such an outage mail can easily be overlooked.
>
>
>
>>
>> Regards,
>>
>> -Rob
>>
>
> thanks for your views, we do have a big gap between your views and what I
> feel is needed.
>
> Maybe I am just too focused on providing 24/7 service, and not something
> with 72hours gaps. I will let the discussion mature before I start doing
> wasted work.
>
> rgds
> jan I.
>
>
>>
>> > have a nice sunday.
>> > 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
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to