Date: prev next · Thread: first prev next last
2022 Archives by date, by thread · List index

Hi Michael, all,

Am 28.05.22 um 18:25 schrieb Michael Weghorn:
Hi Andreas,

On 25/05/2022 22.57, Andreas Mantke wrote:
I have worked together with a group of people on documents during the
last 1.5 year. The documents were not in an editable (e.g. ODF) format.
But everyone, who want to improve one of the documents, was able to
contribute and improve the documents. The format of a document didn't
hinder anyone to submit a valuable proposal / addition.

I want to add that this group was not made out of developers, but common
office workers.

Do you think that the workflow used there would be worth sharing in
more detail as something that might help in the TDF context as well?
the key were / are not magical tools (we use a messenger and regular
office file formats, e.g. pdf or odf etc.), but the people who drive it
forward. It was important that there are two / three group members which
lead the group and get the workflow running. This are managerial
functions which I expect e.g. from the chairman / -women of a group.

My impression is that there seems to be no clear process of how to
work together on a proposal, how to suggest changes,...
It seemed to be a new territory to work on a proposal / document in
public on a mailing list.

Doesn't the BoD have any defined process for doing so?

(If somehow working together on the ODF version or talking to each
other in person is no option: From a developer's perspective, having
the proposal as plain text in a git repo and then allowing people to
suggest changes and the "proposal owner" reviewing those sounds like
one way that would allow to keep track of suggestions, but that may
not be easily usable for non-developers. Having a plain text version
being discussed on the mailing list and the proposal owner answering
there and integrating changes into the authoritative version sounds
like an alternative that might work instead, while having some more
overhead. But there are probably other ways...)

If you discuss about addition to the document on the mailing list and
add them to a document in another place, you have a media segregation.
This makes a work on the document not easy and some will loose track and
will quit to contribute further.

And shortly after I wrote about this segregation issue it got real in
this context:

And the discussion / process was back again behind closed doors. Seemed
you could kill transparency with such media segregation too (by accident?).

And if you'd use git for such a document you will only cover a small
part of the LibreOffice/TDF community. The non-devs will likely not able
to submit their input within a git repo.

Very true. I'd be very interested to hear whether/how those problems
were avoided when cooperating in the group of people you mentioned above.

See above. It's important to have one or more leaders in the group who
drive the process and manage the group and their communication.

And I want to add another point: you can not always discuss papers and
justify their text to the point where everyone is happy with it. You
could not postpone decisions. It is better to decide promptly.

Unanimity is not the key in the decision making process!


## Free Software Advocate
## Plone add-on developer
## My blog:

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.