Re: Pre-release IRC+video informal meeting?
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Pre-release IRC+video informal meeting?
On 3/29/14 5:29 PM, Dave Fisher wrote: Sent from my iPhone On Mar 29, 2014, at 6:44 AM, Rob Weir robw...@apache.org wrote: On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti pesce...@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
Re: Pre-release IRC+video informal meeting?
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 robw...@apache.org wrote: On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti pesce...@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
Re: Pre-release IRC+video informal meeting?
On Mon, Mar 31, 2014 at 1:37 AM, Jürgen Schmidt jogischm...@gmail.comwrote: On 3/29/14 5:29 PM, Dave Fisher wrote: Sent from my iPhone On Mar 29, 2014, at 6:44 AM, Rob Weir robw...@apache.org wrote: On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti pesce...@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
Re: Pre-release IRC+video informal meeting?
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Pre-release IRC+video informal meeting?
On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti pesce...@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-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
Re: Pre-release IRC+video informal meeting?
Sent from my iPhone On Mar 29, 2014, at 6:44 AM, Rob Weir robw...@apache.org wrote: On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti pesce...@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.
Re: Pre-release IRC+video informal meeting?
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
