incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <>
Subject Re: Encouraging participation
Date Fri, 02 Nov 2012 21:12:00 GMT
On 2 November 2012 17:54, Andrea Pescetti <> wrote:

> On 01/11/2012 Rob Weir wrote:
>> On Thu, Nov 1, 2012 at 4:21 PM, jan iversen wrote:
>>> - We need to focus more on people who want to help, instead of using all
>>> the legal stuff (which are necessary) as a buffer not to move things.
>>> (e.g.
>>> I got 2 volunteers working on a danish translation, highly motivated, now
>>> we are discussing details about how to release the stuff).  ...
>> I don't think anyone is using "legal stuff' to prevent things from
>> moving forward.
> There is a bit of confusion here. One thing is allowing volunteers to have
> feedback on their work, the other one is releasing their work. For feedback
> we needn't focus on legal issues. So the Danish translation as discussed in
> will be integrated in any next 3.4.x (informal, i.e., "snapshots") builds.
> The "legal stuff" is not playing any roles here.
>  But it is certainly true that a new volunteer is encouraged the best
>> when they can contribute today and see their results released
>> tomorrow.
> I'd focus on "used" rather than "released": it is more motivating to see
> their results used (i.e., a snapshot build) soon than to see them released
> after months. And this is where we should improve. To give volunteers
> feedback we only need a very lightweight process, ideally zero.
> What is delaying us with the current translations, for example, is just
> that we need to determine a suitable deadline for translators to check in
> their PO files, integrating them on**
> incubator/ooo/branches/AOO34/<>and
building snapshot for AOO34. At the moment this is indeed quite
> demanding on Juergen and Ariel.
>  - I think events like ApacheCon is nice, but events like FOSDEM is quite a
>>> lot more important for the "ordinary" openSource developer.
>> And we are planning a dev room at Fosdem for that reason.
> By FOSDEM (and ideally much earlier) we must be ready to integrate new
> volunteers in a way that fully satisfies them and the project. This is a
> priority for OpenOffice as a project.
> We are getting close to this for what concerns localization: I expect that
> in a couple weeks we will be able to involve, engage and satisfy
> localization volunteers with an established process. We must then do the
> same for QA, development, Marketing...
> An important result we should achieve is that nobody should feel
> frustrated by not having committer privileges: it is also up to us to
> define tasks that can be done without depending too much on a committer
> helping the contributor. At least we should warn them: if someone wants to
> rebuild an entire section of the OpenOffice website, like it is happening
> with Jan, he should be told in advance that this contribution is really
> welcome (and that, for most sections, we really need it!) but that at a
> certain point he might feel frustration for not being a committer. There
> are hundreds of tasks that can be done by non-committers, and we should
> keep the distinction clear when we advertise tasks for volunteers. (That
> said, the "privileges" of being a committer or a PMC member are greatly
> exaggerated at times... it's not that much really; but when this is the
> only obstacle to getting things really done, I can understand the
> impatience).

I think I got ample warning ahead of doing the rewrite of l10n, what
surprised was the discussion going on right now, that is quite frustrating,
especially because I opened the theme before I did the work, and nobody
complained, on the contrary many said "yes please do".

If you things like I do it can be quite frustrating not to have committer
status, not at all for the privilege, but because I have to waster a
committers valuable time, doing simple jobs. So the sentence "it's not that
much really", is not quite correct, it can be quite time saving.

> Regards,
>   Andrea.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message