You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andrea Pescetti <pe...@apache.org> on 2014/03/27 01:59:47 UTC
Pre-release IRC+video informal meeting?
I proposed this in another thread a couple weeks ago, but I didn't
follow up.
Is there interest for a "live" (meaning: IRC + video, like Google
Hangouts or similar) meeting to make sure that we (developers, QA,
Localization, Documentation, website...) are all on the same page
regarding the upcoming 4.1 release?
Our conversations are scattered across many places and it would be great
to have an occasion to bring together, in a totally informal way, active
volunteers from all areas.
It wouldn't be a meeting where things are decided (we have the lists for
that!), but merely a meeting where people can inform each other to make
sure that all priorities are being addressed: interesting bug reports
that need verification, bugs that might qualify as stoppers but that
need a developer to take a look, improvements to the release notes to
better describe new features, localization of release notes, changes to
be done to the localized websites to serve the new release...
As for date/time, for sure one or two developers should attend for the
meeting to make sense, so I would leave to them total freedom in picking
the right date/time.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Pre-release IRC+video informal meeting?
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/31/14 10:37 AM, Jürgen Schmidt wrote:
> On 3/29/14 5:29 PM, Dave Fisher wrote:
>>
>>
>> Sent from my iPhone
>>
>>> On Mar 29, 2014, at 6:44 AM, Rob Weir <ro...@apache.org> wrote:
>>>
>>>> On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti <pe...@apache.org> wrote:
>>>>> On 27/03/2014 Jürgen Schmidt wrote:
>>>>>
>>>>>> On 3/27/14 1:59 AM, Andrea Pescetti wrote:
>>>>>>
>>>>>> Is there interest for a "live" (meaning: IRC + video, like Google
>>>>>> Hangouts or similar) meeting to make sure that we (developers, QA,
>>>>>> Localization, Documentation, website...) are all on the same page
>>>>>> regarding the upcoming 4.1 release?
>>>>>
>>>>> we can try such a meeting but I don't see the benefit compared to a
>>>>> clear communication on the mailing list (can be of course improved).
>>>>
>>>>
>>>> The benefit would be: make sure that active volunteers have a chance to be
>>>> heard and to influence the release. We are doing good now; still, we can do
>>>> better. See below for concrete examples.
>>>>
>>>>
>>>>> Either we do it in a more organized way and define exactly what we
>>>>> expect or I am not interested.
>>>>
>>>>
>>>> I am not interested in the other option. Well, maybe I misunderstood what
>>>> you mean by "organized", but for sure I would find it overkill that we have
>>>> to vote for someone to be in a call to represent a certain group (say, QA)
>>>> and vote on what the call topics should be. It's an informal meeting.
>>>>
>>>>>> It wouldn't be a meeting where things are decided (we have the lists for
>>>>>> that!), but merely a meeting where people can inform each other to make
>>>>>> sure that all priorities are being addressed ...
>>>>>
>>>>> I am in favor of having such discussion mainly on the list to have it
>>>>> documented.
>>>>
>>>>
>>>> Note that it's more about being informed (about stuff that is already
>>>> somewhere on the lists), and discussion can follow on lists.
>>>>
>>>> Maybe it helps if I make a concrete past example: the "Restore windows"
>>>> problem https://issues.apache.org/ooo/show_bug.cgi?id=119006 has been known
>>>> for two years. It only triggered on certain versions of Mac OS X and only
>>>> after a crash. Still it caused 500+ e-mails, and probably countless forum
>>>> posts and some enraged/lost users. In retrospect, we should have evaluated
>>>> it better.
>>>>
>>>> How can we avoid the next "Restore windows", i.e., something that is known,
>>>> important to someone, already documented somewhere but that would deserve
>>>> better attention? It's important for OpenOffice as a project that active
>>>> volunteers feel that they can influence the release. And it is also very
>>>> good for OpenOffice as a product.
>>>>
>>>> Now, the obvious answer is "Just place it in Bugzilla and nominate it as a
>>>> release blocker". This doesn't always work. For a release blocker, for
>>>> example, you would require in most cases that a patch is available, and a
>>>> description that is purely technical can miss to state why it is important
>>>> to get it fixed before release. And if you look at who is nominating
>>>> blockers, you'll see that only a few people do that.
>>>>
>>>> The IRC+video meeting is the best solution I can find, but anything else
>>>> that guarantees proper escalation would work for me. Just, asking people to
>>>> simply follow the process is too demanding on volunteers and we need to
>>>> streamline it (another concrete example? we don't have 4.0 in Danish mainly
>>>> due to bad communication, since translation was completed before the 4.0
>>>> release but after the deadlines).
>>>>
>>>> If you want yet another example... we already know that OpenOffice 4.1 is
>>>> going to have display problems for Gnome 3 users on Linux. Two bugs have
>>>> clearly been identified: no refresh on fields
>>>> https://issues.apache.org/ooo/show_bug.cgi?id=124482 and no scrollbars
>>>> https://issues.apache.org/ooo/show_bug.cgi?id=121627 ; the former has a
>>>> working patch by Andre and I'll nominate it as a blocker, but what about the
>>>> latter? Does it make sense to nominate it even if we don't have a fix
>>>> available? Will a meeting where active people can report on what they see on
>>>> the forums, lists etc help in making the assessment?
>>>
>>> We can always have a Hangout on our Google+ page. But I think that is
>>> limited to 10 people and ties us to a specific time, making it more or
>>> less convenient to people depending on their timezone. So I'm not
>>> sure it is much more inclusive.
>>>
>>> But you could make the argument that it is a best practice with Agile
>>> methodology for us to have "daily scrum" meeting to check in and
>>> review blockers. But that could also be done via the mailing list,
>>> with a new thread each day, e.g., "2014-03-29 Daily Scrum".
>>
>> As I read the other emails I was thinking that a bug scrub would be good. This would allow a group to discuss bugs and issues. The goal would be a priority list which could then be shared on list, debated. We can then commit ( agile term). Daily scrum then tracks the progress towards the goal. The scrum master records the info. Scrum master can change from day to day. It is clerical.
>>
>
> we can stop discussion on such scrum or whatever meetings as long as we
> don't have more developers.
>
> Take a look on the issues that came in over the weekend, 124553 a crash
> on Linux when you select a table and some text below or before. I am
> really asking if anybody has used the Beta version on Linux and used
> form some simple tasks? And taking this issue as example should we
> really accept Linux issues as showstopper?
>
> Ok don't take me to serious but I hope you see my point. We have a
> problem but that can't be solved with such meetings.
>
> @andrea, my point is that I am not interested in an informal meeting
> without a special outcome. Issues of broader interest get attention if
> they are communicated on the list and we have no timezone issues.
>
> But we don't need a Beta in the future if such issues as above are not
> found over month.
>
> Nevertheless will be a new snapshot available later today (hopefully if
> the upload of the windows builds is fast enough).
I dropped the upload and removed all builds for Linux and Mac as well.
We will fix some serious issues an dI hope we can hold the Wednesday
schedule
Juergen
>
> Juergen
>
>
>
>> Regards,
>> Dave
>>
>>>
>>> In any case, if a PMC member wants to take the lead on a hangout, and
>>> does not already have access to our Google+ page, let me know and I
>>> can give you manager access.
>>>
>>> -Rob
>>>
>>>
>>>> Regards,
>>>> Andrea.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Pre-release IRC+video informal meeting?
Posted by Andrea Pescetti <pe...@apache.org>.
On 31/03/2014 Jürgen Schmidt wrote:
> @andrea, my point is that I am not interested in an informal meeting
> without a special outcome. Issues of broader interest get attention if
> they are communicated on the list and we have no timezone issues.
I probably mixed the problem with a proposed solution that is not the
optimal one. I'm not so interested in the form of this meeting, IRC or
video or anything. And it doesn't have to be focused on the pre-release
activities.
My concern is that currently:
1) It's hard for volunteers to know if their needs are being addressed
or not and how the "big picture" looks like in their areas of interest.
For example, I would be able to report on the Localization activities: I
know what the community priorities are in that respect, what is being
neglected, what should be improved. I don't have the same clarity of
vision in QA for example: I would love that someone who is more active
in QA tells us things like "a lot of new bugs are reported for Impress"
or "we have many duplicate bug reports that are Linux-specific" (both
invented). This would help the project to have clearer priorities. The
"Here's an important bug that we need developers to comment on" is only
part of this.
2) Conversely, it's hard for developers to delegate some tasks. Example
(just an example, don't comment on this): I am active in Localization
but it's still unclear to most people how we import the old translations
into Pootle; we shouldn't expect that a volunteer explicitly asks if he
can help with that; if we knew what the needed skills are, we could
involve more people and take some workload off the "main" developers,
Juergen in this case. Probably this is true of many other cases, it just
needs better communication.
So, my new iteration of the issue is: how can we force this
communication to happen in an effective way? Many open source projects,
even with a completely different structure than OpenOffice, have a
periodic IRC meeting where community-selected items are discussed. Could
we try something like that, still keeping in mind that decisions are
taken on lists and that this would be a communication/awareness improvement?
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Pre-release IRC+video informal meeting?
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Mar 31, 2014 at 1:37 AM, Jürgen Schmidt <jo...@gmail.com>wrote:
> On 3/29/14 5:29 PM, Dave Fisher wrote:
> >
> >
> > Sent from my iPhone
> >
> >> On Mar 29, 2014, at 6:44 AM, Rob Weir <ro...@apache.org> wrote:
> >>
> >>> On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti <pe...@apache.org>
> wrote:
> >>>> On 27/03/2014 Jürgen Schmidt wrote:
> >>>>
> >>>>> On 3/27/14 1:59 AM, Andrea Pescetti wrote:
> >>>>>
> >>>>> Is there interest for a "live" (meaning: IRC + video, like Google
> >>>>> Hangouts or similar) meeting to make sure that we (developers, QA,
> >>>>> Localization, Documentation, website...) are all on the same page
> >>>>> regarding the upcoming 4.1 release?
> >>>>
> >>>> we can try such a meeting but I don't see the benefit compared to a
> >>>> clear communication on the mailing list (can be of course improved).
> >>>
> >>>
> >>> The benefit would be: make sure that active volunteers have a chance
> to be
> >>> heard and to influence the release. We are doing good now; still, we
> can do
> >>> better. See below for concrete examples.
> >>>
> >>>
> >>>> Either we do it in a more organized way and define exactly what we
> >>>> expect or I am not interested.
> >>>
> >>>
> >>> I am not interested in the other option. Well, maybe I misunderstood
> what
> >>> you mean by "organized", but for sure I would find it overkill that we
> have
> >>> to vote for someone to be in a call to represent a certain group (say,
> QA)
> >>> and vote on what the call topics should be. It's an informal meeting.
> >>>
> >>>>> It wouldn't be a meeting where things are decided (we have the lists
> for
> >>>>> that!), but merely a meeting where people can inform each other to
> make
> >>>>> sure that all priorities are being addressed ...
> >>>>
> >>>> I am in favor of having such discussion mainly on the list to have it
> >>>> documented.
> >>>
> >>>
> >>> Note that it's more about being informed (about stuff that is already
> >>> somewhere on the lists), and discussion can follow on lists.
> >>>
> >>> Maybe it helps if I make a concrete past example: the "Restore windows"
> >>> problem https://issues.apache.org/ooo/show_bug.cgi?id=119006 has been
> known
> >>> for two years. It only triggered on certain versions of Mac OS X and
> only
> >>> after a crash. Still it caused 500+ e-mails, and probably countless
> forum
> >>> posts and some enraged/lost users. In retrospect, we should have
> evaluated
> >>> it better.
> >>>
> >>> How can we avoid the next "Restore windows", i.e., something that is
> known,
> >>> important to someone, already documented somewhere but that would
> deserve
> >>> better attention? It's important for OpenOffice as a project that
> active
> >>> volunteers feel that they can influence the release. And it is also
> very
> >>> good for OpenOffice as a product.
> >>>
> >>> Now, the obvious answer is "Just place it in Bugzilla and nominate it
> as a
> >>> release blocker". This doesn't always work. For a release blocker, for
> >>> example, you would require in most cases that a patch is available,
> and a
> >>> description that is purely technical can miss to state why it is
> important
> >>> to get it fixed before release. And if you look at who is nominating
> >>> blockers, you'll see that only a few people do that.
> >>>
> >>> The IRC+video meeting is the best solution I can find, but anything
> else
> >>> that guarantees proper escalation would work for me. Just, asking
> people to
> >>> simply follow the process is too demanding on volunteers and we need to
> >>> streamline it (another concrete example? we don't have 4.0 in Danish
> mainly
> >>> due to bad communication, since translation was completed before the
> 4.0
> >>> release but after the deadlines).
> >>>
> >>> If you want yet another example... we already know that OpenOffice 4.1
> is
> >>> going to have display problems for Gnome 3 users on Linux. Two bugs
> have
> >>> clearly been identified: no refresh on fields
> >>> https://issues.apache.org/ooo/show_bug.cgi?id=124482 and no scrollbars
> >>> https://issues.apache.org/ooo/show_bug.cgi?id=121627 ; the former has
> a
> >>> working patch by Andre and I'll nominate it as a blocker, but what
> about the
> >>> latter? Does it make sense to nominate it even if we don't have a fix
> >>> available? Will a meeting where active people can report on what they
> see on
> >>> the forums, lists etc help in making the assessment?
> >>
> >> We can always have a Hangout on our Google+ page. But I think that is
> >> limited to 10 people and ties us to a specific time, making it more or
> >> less convenient to people depending on their timezone. So I'm not
> >> sure it is much more inclusive.
> >>
> >> But you could make the argument that it is a best practice with Agile
> >> methodology for us to have "daily scrum" meeting to check in and
> >> review blockers. But that could also be done via the mailing list,
> >> with a new thread each day, e.g., "2014-03-29 Daily Scrum".
> >
> > As I read the other emails I was thinking that a bug scrub would be
> good. This would allow a group to discuss bugs and issues. The goal would
> be a priority list which could then be shared on list, debated. We can then
> commit ( agile term). Daily scrum then tracks the progress towards the
> goal. The scrum master records the info. Scrum master can change from day
> to day. It is clerical.
> >
>
> we can stop discussion on such scrum or whatever meetings as long as we
> don't have more developers.
>
> Take a look on the issues that came in over the weekend, 124553 a crash
> on Linux when you select a table and some text below or before. I am
> really asking if anybody has used the Beta version on Linux and used
> form some simple tasks? And taking this issue as example should we
> really accept Linux issues as showstopper?
>
Well...two opinions from me:
* yes, Linux issues should be used as showstoppers when appropriate. The
issue here is there are a variety of Linux architectures -- 32- and 64-bit,
and a variety of graphical environments. A number of us DO test on Linux,
but as the old saying goes -- "Your mileage may vary."
* I'm much prefer mailing lists for ANY planning and discussion. If
needed, "proposed showstoppers" can be discussed at length.
> Ok don't take me to serious but I hope you see my point. We have a
> problem but that can't be solved with such meetings.
>
> @andrea, my point is that I am not interested in an informal meeting
> without a special outcome. Issues of broader interest get attention if
> they are communicated on the list and we have no timezone issues.
>
> But we don't need a Beta in the future if such issues as above are not
> found over month.
>
> Nevertheless will be a new snapshot available later today (hopefully if
> the upload of the windows builds is fast enough).
>
> Juergen
>
>
>
> > Regards,
> > Dave
> >
> >>
> >> In any case, if a PMC member wants to take the lead on a hangout, and
> >> does not already have access to our Google+ page, let me know and I
> >> can give you manager access.
> >>
> >> -Rob
> >>
> >>
> >>> Regards,
> >>> Andrea.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Pre-release IRC+video informal meeting?
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/29/14 5:29 PM, Dave Fisher wrote:
>
>
> Sent from my iPhone
>
>> On Mar 29, 2014, at 6:44 AM, Rob Weir <ro...@apache.org> wrote:
>>
>>> On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti <pe...@apache.org> wrote:
>>>> On 27/03/2014 Jürgen Schmidt wrote:
>>>>
>>>>> On 3/27/14 1:59 AM, Andrea Pescetti wrote:
>>>>>
>>>>> Is there interest for a "live" (meaning: IRC + video, like Google
>>>>> Hangouts or similar) meeting to make sure that we (developers, QA,
>>>>> Localization, Documentation, website...) are all on the same page
>>>>> regarding the upcoming 4.1 release?
>>>>
>>>> we can try such a meeting but I don't see the benefit compared to a
>>>> clear communication on the mailing list (can be of course improved).
>>>
>>>
>>> The benefit would be: make sure that active volunteers have a chance to be
>>> heard and to influence the release. We are doing good now; still, we can do
>>> better. See below for concrete examples.
>>>
>>>
>>>> Either we do it in a more organized way and define exactly what we
>>>> expect or I am not interested.
>>>
>>>
>>> I am not interested in the other option. Well, maybe I misunderstood what
>>> you mean by "organized", but for sure I would find it overkill that we have
>>> to vote for someone to be in a call to represent a certain group (say, QA)
>>> and vote on what the call topics should be. It's an informal meeting.
>>>
>>>>> It wouldn't be a meeting where things are decided (we have the lists for
>>>>> that!), but merely a meeting where people can inform each other to make
>>>>> sure that all priorities are being addressed ...
>>>>
>>>> I am in favor of having such discussion mainly on the list to have it
>>>> documented.
>>>
>>>
>>> Note that it's more about being informed (about stuff that is already
>>> somewhere on the lists), and discussion can follow on lists.
>>>
>>> Maybe it helps if I make a concrete past example: the "Restore windows"
>>> problem https://issues.apache.org/ooo/show_bug.cgi?id=119006 has been known
>>> for two years. It only triggered on certain versions of Mac OS X and only
>>> after a crash. Still it caused 500+ e-mails, and probably countless forum
>>> posts and some enraged/lost users. In retrospect, we should have evaluated
>>> it better.
>>>
>>> How can we avoid the next "Restore windows", i.e., something that is known,
>>> important to someone, already documented somewhere but that would deserve
>>> better attention? It's important for OpenOffice as a project that active
>>> volunteers feel that they can influence the release. And it is also very
>>> good for OpenOffice as a product.
>>>
>>> Now, the obvious answer is "Just place it in Bugzilla and nominate it as a
>>> release blocker". This doesn't always work. For a release blocker, for
>>> example, you would require in most cases that a patch is available, and a
>>> description that is purely technical can miss to state why it is important
>>> to get it fixed before release. And if you look at who is nominating
>>> blockers, you'll see that only a few people do that.
>>>
>>> The IRC+video meeting is the best solution I can find, but anything else
>>> that guarantees proper escalation would work for me. Just, asking people to
>>> simply follow the process is too demanding on volunteers and we need to
>>> streamline it (another concrete example? we don't have 4.0 in Danish mainly
>>> due to bad communication, since translation was completed before the 4.0
>>> release but after the deadlines).
>>>
>>> If you want yet another example... we already know that OpenOffice 4.1 is
>>> going to have display problems for Gnome 3 users on Linux. Two bugs have
>>> clearly been identified: no refresh on fields
>>> https://issues.apache.org/ooo/show_bug.cgi?id=124482 and no scrollbars
>>> https://issues.apache.org/ooo/show_bug.cgi?id=121627 ; the former has a
>>> working patch by Andre and I'll nominate it as a blocker, but what about the
>>> latter? Does it make sense to nominate it even if we don't have a fix
>>> available? Will a meeting where active people can report on what they see on
>>> the forums, lists etc help in making the assessment?
>>
>> We can always have a Hangout on our Google+ page. But I think that is
>> limited to 10 people and ties us to a specific time, making it more or
>> less convenient to people depending on their timezone. So I'm not
>> sure it is much more inclusive.
>>
>> But you could make the argument that it is a best practice with Agile
>> methodology for us to have "daily scrum" meeting to check in and
>> review blockers. But that could also be done via the mailing list,
>> with a new thread each day, e.g., "2014-03-29 Daily Scrum".
>
> As I read the other emails I was thinking that a bug scrub would be good. This would allow a group to discuss bugs and issues. The goal would be a priority list which could then be shared on list, debated. We can then commit ( agile term). Daily scrum then tracks the progress towards the goal. The scrum master records the info. Scrum master can change from day to day. It is clerical.
>
we can stop discussion on such scrum or whatever meetings as long as we
don't have more developers.
Take a look on the issues that came in over the weekend, 124553 a crash
on Linux when you select a table and some text below or before. I am
really asking if anybody has used the Beta version on Linux and used
form some simple tasks? And taking this issue as example should we
really accept Linux issues as showstopper?
Ok don't take me to serious but I hope you see my point. We have a
problem but that can't be solved with such meetings.
@andrea, my point is that I am not interested in an informal meeting
without a special outcome. Issues of broader interest get attention if
they are communicated on the list and we have no timezone issues.
But we don't need a Beta in the future if such issues as above are not
found over month.
Nevertheless will be a new snapshot available later today (hopefully if
the upload of the windows builds is fast enough).
Juergen
> Regards,
> Dave
>
>>
>> In any case, if a PMC member wants to take the lead on a hangout, and
>> does not already have access to our Google+ page, let me know and I
>> can give you manager access.
>>
>> -Rob
>>
>>
>>> Regards,
>>> Andrea.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Pre-release IRC+video informal meeting?
Posted by Dave Fisher <wa...@apache.org>.
Sent from my iPhone
> On Mar 29, 2014, at 6:44 AM, Rob Weir <ro...@apache.org> wrote:
>
>> On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti <pe...@apache.org> wrote:
>>> On 27/03/2014 Jürgen Schmidt wrote:
>>>
>>>> On 3/27/14 1:59 AM, Andrea Pescetti wrote:
>>>>
>>>> Is there interest for a "live" (meaning: IRC + video, like Google
>>>> Hangouts or similar) meeting to make sure that we (developers, QA,
>>>> Localization, Documentation, website...) are all on the same page
>>>> regarding the upcoming 4.1 release?
>>>
>>> we can try such a meeting but I don't see the benefit compared to a
>>> clear communication on the mailing list (can be of course improved).
>>
>>
>> The benefit would be: make sure that active volunteers have a chance to be
>> heard and to influence the release. We are doing good now; still, we can do
>> better. See below for concrete examples.
>>
>>
>>> Either we do it in a more organized way and define exactly what we
>>> expect or I am not interested.
>>
>>
>> I am not interested in the other option. Well, maybe I misunderstood what
>> you mean by "organized", but for sure I would find it overkill that we have
>> to vote for someone to be in a call to represent a certain group (say, QA)
>> and vote on what the call topics should be. It's an informal meeting.
>>
>>>> It wouldn't be a meeting where things are decided (we have the lists for
>>>> that!), but merely a meeting where people can inform each other to make
>>>> sure that all priorities are being addressed ...
>>>
>>> I am in favor of having such discussion mainly on the list to have it
>>> documented.
>>
>>
>> Note that it's more about being informed (about stuff that is already
>> somewhere on the lists), and discussion can follow on lists.
>>
>> Maybe it helps if I make a concrete past example: the "Restore windows"
>> problem https://issues.apache.org/ooo/show_bug.cgi?id=119006 has been known
>> for two years. It only triggered on certain versions of Mac OS X and only
>> after a crash. Still it caused 500+ e-mails, and probably countless forum
>> posts and some enraged/lost users. In retrospect, we should have evaluated
>> it better.
>>
>> How can we avoid the next "Restore windows", i.e., something that is known,
>> important to someone, already documented somewhere but that would deserve
>> better attention? It's important for OpenOffice as a project that active
>> volunteers feel that they can influence the release. And it is also very
>> good for OpenOffice as a product.
>>
>> Now, the obvious answer is "Just place it in Bugzilla and nominate it as a
>> release blocker". This doesn't always work. For a release blocker, for
>> example, you would require in most cases that a patch is available, and a
>> description that is purely technical can miss to state why it is important
>> to get it fixed before release. And if you look at who is nominating
>> blockers, you'll see that only a few people do that.
>>
>> The IRC+video meeting is the best solution I can find, but anything else
>> that guarantees proper escalation would work for me. Just, asking people to
>> simply follow the process is too demanding on volunteers and we need to
>> streamline it (another concrete example? we don't have 4.0 in Danish mainly
>> due to bad communication, since translation was completed before the 4.0
>> release but after the deadlines).
>>
>> If you want yet another example... we already know that OpenOffice 4.1 is
>> going to have display problems for Gnome 3 users on Linux. Two bugs have
>> clearly been identified: no refresh on fields
>> https://issues.apache.org/ooo/show_bug.cgi?id=124482 and no scrollbars
>> https://issues.apache.org/ooo/show_bug.cgi?id=121627 ; the former has a
>> working patch by Andre and I'll nominate it as a blocker, but what about the
>> latter? Does it make sense to nominate it even if we don't have a fix
>> available? Will a meeting where active people can report on what they see on
>> the forums, lists etc help in making the assessment?
>
> We can always have a Hangout on our Google+ page. But I think that is
> limited to 10 people and ties us to a specific time, making it more or
> less convenient to people depending on their timezone. So I'm not
> sure it is much more inclusive.
>
> But you could make the argument that it is a best practice with Agile
> methodology for us to have "daily scrum" meeting to check in and
> review blockers. But that could also be done via the mailing list,
> with a new thread each day, e.g., "2014-03-29 Daily Scrum".
As I read the other emails I was thinking that a bug scrub would be good. This would allow a group to discuss bugs and issues. The goal would be a priority list which could then be shared on list, debated. We can then commit ( agile term). Daily scrum then tracks the progress towards the goal. The scrum master records the info. Scrum master can change from day to day. It is clerical.
Regards,
Dave
>
> In any case, if a PMC member wants to take the lead on a hangout, and
> does not already have access to our Google+ page, let me know and I
> can give you manager access.
>
> -Rob
>
>
>> Regards,
>> Andrea.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Pre-release IRC+video informal meeting?
Posted by Rob Weir <ro...@apache.org>.
On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti <pe...@apache.org> wrote:
> On 27/03/2014 Jürgen Schmidt wrote:
>>
>> On 3/27/14 1:59 AM, Andrea Pescetti wrote:
>>>
>>> Is there interest for a "live" (meaning: IRC + video, like Google
>>> Hangouts or similar) meeting to make sure that we (developers, QA,
>>> Localization, Documentation, website...) are all on the same page
>>> regarding the upcoming 4.1 release?
>>
>> we can try such a meeting but I don't see the benefit compared to a
>> clear communication on the mailing list (can be of course improved).
>
>
> The benefit would be: make sure that active volunteers have a chance to be
> heard and to influence the release. We are doing good now; still, we can do
> better. See below for concrete examples.
>
>
>> Either we do it in a more organized way and define exactly what we
>> expect or I am not interested.
>
>
> I am not interested in the other option. Well, maybe I misunderstood what
> you mean by "organized", but for sure I would find it overkill that we have
> to vote for someone to be in a call to represent a certain group (say, QA)
> and vote on what the call topics should be. It's an informal meeting.
>
>>> It wouldn't be a meeting where things are decided (we have the lists for
>>> that!), but merely a meeting where people can inform each other to make
>>> sure that all priorities are being addressed ...
>>
>> I am in favor of having such discussion mainly on the list to have it
>> documented.
>
>
> Note that it's more about being informed (about stuff that is already
> somewhere on the lists), and discussion can follow on lists.
>
> Maybe it helps if I make a concrete past example: the "Restore windows"
> problem https://issues.apache.org/ooo/show_bug.cgi?id=119006 has been known
> for two years. It only triggered on certain versions of Mac OS X and only
> after a crash. Still it caused 500+ e-mails, and probably countless forum
> posts and some enraged/lost users. In retrospect, we should have evaluated
> it better.
>
> How can we avoid the next "Restore windows", i.e., something that is known,
> important to someone, already documented somewhere but that would deserve
> better attention? It's important for OpenOffice as a project that active
> volunteers feel that they can influence the release. And it is also very
> good for OpenOffice as a product.
>
> Now, the obvious answer is "Just place it in Bugzilla and nominate it as a
> release blocker". This doesn't always work. For a release blocker, for
> example, you would require in most cases that a patch is available, and a
> description that is purely technical can miss to state why it is important
> to get it fixed before release. And if you look at who is nominating
> blockers, you'll see that only a few people do that.
>
> The IRC+video meeting is the best solution I can find, but anything else
> that guarantees proper escalation would work for me. Just, asking people to
> simply follow the process is too demanding on volunteers and we need to
> streamline it (another concrete example? we don't have 4.0 in Danish mainly
> due to bad communication, since translation was completed before the 4.0
> release but after the deadlines).
>
> If you want yet another example... we already know that OpenOffice 4.1 is
> going to have display problems for Gnome 3 users on Linux. Two bugs have
> clearly been identified: no refresh on fields
> https://issues.apache.org/ooo/show_bug.cgi?id=124482 and no scrollbars
> https://issues.apache.org/ooo/show_bug.cgi?id=121627 ; the former has a
> working patch by Andre and I'll nominate it as a blocker, but what about the
> latter? Does it make sense to nominate it even if we don't have a fix
> available? Will a meeting where active people can report on what they see on
> the forums, lists etc help in making the assessment?
>
We can always have a Hangout on our Google+ page. But I think that is
limited to 10 people and ties us to a specific time, making it more or
less convenient to people depending on their timezone. So I'm not
sure it is much more inclusive.
But you could make the argument that it is a best practice with Agile
methodology for us to have "daily scrum" meeting to check in and
review blockers. But that could also be done via the mailing list,
with a new thread each day, e.g., "2014-03-29 Daily Scrum".
In any case, if a PMC member wants to take the lead on a hangout, and
does not already have access to our Google+ page, let me know and I
can give you manager access.
-Rob
> Regards,
> Andrea.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Pre-release IRC+video informal meeting?
Posted by Andre Fischer <aw...@gmail.com>.
On 29.03.2014 12:14, Andrea Pescetti wrote:
> On 27/03/2014 Jürgen Schmidt wrote:
>> On 3/27/14 1:59 AM, Andrea Pescetti wrote:
>>> Is there interest for a "live" (meaning: IRC + video, like Google
>>> Hangouts or similar) meeting to make sure that we (developers, QA,
>>> Localization, Documentation, website...) are all on the same page
>>> regarding the upcoming 4.1 release?
>> we can try such a meeting but I don't see the benefit compared to a
>> clear communication on the mailing list (can be of course improved).
>
> The benefit would be: make sure that active volunteers have a chance
> to be heard and to influence the release. We are doing good now;
> still, we can do better. See below for concrete examples.
>
>> Either we do it in a more organized way and define exactly what we
>> expect or I am not interested.
>
> I am not interested in the other option. Well, maybe I misunderstood
> what you mean by "organized", but for sure I would find it overkill
> that we have to vote for someone to be in a call to represent a
> certain group (say, QA) and vote on what the call topics should be.
> It's an informal meeting.
>
>>> It wouldn't be a meeting where things are decided (we have the lists
>>> for
>>> that!), but merely a meeting where people can inform each other to make
>>> sure that all priorities are being addressed ...
>> I am in favor of having such discussion mainly on the list to have it
>> documented.
>
> Note that it's more about being informed (about stuff that is already
> somewhere on the lists), and discussion can follow on lists.
>
> Maybe it helps if I make a concrete past example: the "Restore
> windows" problem https://issues.apache.org/ooo/show_bug.cgi?id=119006
> has been known for two years. It only triggered on certain versions of
> Mac OS X and only after a crash. Still it caused 500+ e-mails, and
> probably countless forum posts and some enraged/lost users. In
> retrospect, we should have evaluated it better.
>
> How can we avoid the next "Restore windows", i.e., something that is
> known, important to someone, already documented somewhere but that
> would deserve better attention? It's important for OpenOffice as a
> project that active volunteers feel that they can influence the
> release. And it is also very good for OpenOffice as a product.
>
> Now, the obvious answer is "Just place it in Bugzilla and nominate it
> as a release blocker". This doesn't always work. For a release
> blocker, for example, you would require in most cases that a patch is
> available, and a description that is purely technical can miss to
> state why it is important to get it fixed before release. And if you
> look at who is nominating blockers, you'll see that only a few people
> do that.
>
> The IRC+video meeting is the best solution I can find, but anything
> else that guarantees proper escalation would work for me. Just, asking
> people to simply follow the process is too demanding on volunteers and
> we need to streamline it (another concrete example? we don't have 4.0
> in Danish mainly due to bad communication, since translation was
> completed before the 4.0 release but after the deadlines).
>
> If you want yet another example... we already know that OpenOffice 4.1
> is going to have display problems for Gnome 3 users on Linux. Two bugs
> have clearly been identified: no refresh on fields
> https://issues.apache.org/ooo/show_bug.cgi?id=124482 and no scrollbars
> https://issues.apache.org/ooo/show_bug.cgi?id=121627 ; the former has
> a working patch by Andre and I'll nominate it as a blocker, but what
> about the latter? Does it make sense to nominate it even if we don't
> have a fix available? Will a meeting where active people can report on
> what they see on the forums, lists etc help in making the assessment?
>
These are valid examples that have to be addressed. Why not on the
mailing list? I don't object to video conference or IRC but personally
I prefer communication by mail. It allows me to take the time to think
about what others say and about may reply. It also gives me time for
technical analysis of the bugs.
-Andre
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Pre-release IRC+video informal meeting?
Posted by Andrea Pescetti <pe...@apache.org>.
On 27/03/2014 Jürgen Schmidt wrote:
> On 3/27/14 1:59 AM, Andrea Pescetti wrote:
>> Is there interest for a "live" (meaning: IRC + video, like Google
>> Hangouts or similar) meeting to make sure that we (developers, QA,
>> Localization, Documentation, website...) are all on the same page
>> regarding the upcoming 4.1 release?
> we can try such a meeting but I don't see the benefit compared to a
> clear communication on the mailing list (can be of course improved).
The benefit would be: make sure that active volunteers have a chance to
be heard and to influence the release. We are doing good now; still, we
can do better. See below for concrete examples.
> Either we do it in a more organized way and define exactly what we
> expect or I am not interested.
I am not interested in the other option. Well, maybe I misunderstood
what you mean by "organized", but for sure I would find it overkill that
we have to vote for someone to be in a call to represent a certain group
(say, QA) and vote on what the call topics should be. It's an informal
meeting.
>> It wouldn't be a meeting where things are decided (we have the lists for
>> that!), but merely a meeting where people can inform each other to make
>> sure that all priorities are being addressed ...
> I am in favor of having such discussion mainly on the list to have it
> documented.
Note that it's more about being informed (about stuff that is already
somewhere on the lists), and discussion can follow on lists.
Maybe it helps if I make a concrete past example: the "Restore windows"
problem https://issues.apache.org/ooo/show_bug.cgi?id=119006 has been
known for two years. It only triggered on certain versions of Mac OS X
and only after a crash. Still it caused 500+ e-mails, and probably
countless forum posts and some enraged/lost users. In retrospect, we
should have evaluated it better.
How can we avoid the next "Restore windows", i.e., something that is
known, important to someone, already documented somewhere but that would
deserve better attention? It's important for OpenOffice as a project
that active volunteers feel that they can influence the release. And it
is also very good for OpenOffice as a product.
Now, the obvious answer is "Just place it in Bugzilla and nominate it as
a release blocker". This doesn't always work. For a release blocker, for
example, you would require in most cases that a patch is available, and
a description that is purely technical can miss to state why it is
important to get it fixed before release. And if you look at who is
nominating blockers, you'll see that only a few people do that.
The IRC+video meeting is the best solution I can find, but anything else
that guarantees proper escalation would work for me. Just, asking people
to simply follow the process is too demanding on volunteers and we need
to streamline it (another concrete example? we don't have 4.0 in Danish
mainly due to bad communication, since translation was completed before
the 4.0 release but after the deadlines).
If you want yet another example... we already know that OpenOffice 4.1
is going to have display problems for Gnome 3 users on Linux. Two bugs
have clearly been identified: no refresh on fields
https://issues.apache.org/ooo/show_bug.cgi?id=124482 and no scrollbars
https://issues.apache.org/ooo/show_bug.cgi?id=121627 ; the former has a
working patch by Andre and I'll nominate it as a blocker, but what about
the latter? Does it make sense to nominate it even if we don't have a
fix available? Will a meeting where active people can report on what
they see on the forums, lists etc help in making the assessment?
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Pre-release IRC+video informal meeting?
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/27/14 1:59 AM, Andrea Pescetti wrote:
> I proposed this in another thread a couple weeks ago, but I didn't
> follow up.
>
> Is there interest for a "live" (meaning: IRC + video, like Google
> Hangouts or similar) meeting to make sure that we (developers, QA,
> Localization, Documentation, website...) are all on the same page
> regarding the upcoming 4.1 release?
we can try such a meeting but I don't see the benefit compared to a
clear communication on the mailing list (can be of course improved).
Having it on the mailing list is good and everything is documented. The
main problem is the different mailing lists and the not correct using of
our tags (e.g. RELEASE, SOURCE, ...). I at least try to mark all release
relevant mails with RELEASE in the subject.
People can ask, propose or whatever on the mailing list and people in a
different timezone can read and reply later.
>
> Our conversations are scattered across many places and it would be great
> to have an occasion to bring together, in a totally informal way, active
> volunteers from all areas.
Either we do it in a more organized way and define exactly what we
expect or I am not interested. People can discuss on IRC or whatever
media, can collaborate on a proposal and can come back on the list to
share it with the rest.
>
> It wouldn't be a meeting where things are decided (we have the lists for
> that!), but merely a meeting where people can inform each other to make
> sure that all priorities are being addressed: interesting bug reports
> that need verification, bugs that might qualify as stoppers but that
> need a developer to take a look, improvements to the release notes to
> better describe new features, localization of release notes, changes to
> be done to the localized websites to serve the new release...
I am in favor of having such discussion mainly on the list to have it
documented.
>
> As for date/time, for sure one or two developers should attend for the
> meeting to make sense, so I would leave to them total freedom in picking
> the right date/time.
I am open to try it based on more detailed proposal what we want achieve
and how it should work
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org