[CREATE] Collaboration on the Libre Graphics Magazine?

[Dave Crossland]

On 25 September 2010 17:34, Schrijver <eric at authoritism.net> wrote:
>
> Because I have to disagree with:
>
>>  'True' collaboration works with software because, for each problem, you can actually find an objectively satisfying solution.
>
> Objectively satisfying solutions do not exist in code either. Code is highly subjective. One programmer might think of a
> solution as an ‘ugly hack’ while the other might see it as an ‘elegant solution’.

+1

> Than there’s different paradigms of programming: do you like functional or object oriented or declarative or
> whatever? Whether you prefer one over the other is a matter of taste.

And lets not get started on choice of programming language ;-)

>> That said, i'm totally unsure as to how we can find a 'real' collaborative and decentralised model to
>> make a magazine. But i would love to have an answer for that, and hopefully we'll be finding
>> out as we go through with this project.
>
> I think a first, and manageable, step would be to figure out how you can offer up a repository
> with all the text and layout files used for the magazine, in such a way that it becomes easy
> to repurpose.

+1000

I specifically recommend that all source files live in folders watched
by http://www.sparkleshare.org which takes care of checking them into
a Git repo hosted at http://gitorious.org

Then anyone who wants to suggest changes can do so by making the kinds
of changes they want to see, and sending A&R&g a kind pull-request
note, but no effort be put into public participatory collaboration
beyond using SparkleShare.

> This can even be done after the publication.

-1

I suggest that Ana, Ricardo and ginger will find their own work easier
if they do this now. We are always collaborating, if only with our
future selves.

> This might seem really easy, but since the file formats of desktoppublishing tools were not designed to be used in such a way this can already lead to interesting challenges.

Scribus' native file format is plain text; and the word on the
(Belgian) street is that when the text system is remade the file
format could be real XML, or at least, not store text frames' text as
an attribute value.

> Subsequent effort might be applied to using such a repository as a collaboration tool.

+1

> and am looking forward to this awesome project :)

We'd better start drafting submissions :)

-- 
Cheers
Dave