openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: Pre-release IRC+video informal meeting?
Date Mon, 31 Mar 2014 08:37:17 GMT
On 3/29/14 5:29 PM, Dave Fisher wrote:
> Sent from my iPhone
>> On Mar 29, 2014, at 6:44 AM, Rob Weir <> wrote:
>>> On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti <>
>>>> 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
>>>>> 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 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
>>> and no scrollbars
>>> ; 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).


> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message