[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: [kde-community] Proposal: KDE Manifesto wording revision
From:       Eike Hein <hein () kde ! org>
Date:       2013-11-13 20:39:00
Message-ID: 2421930.anfCEbs2QZ () ehw1 ! ehn
[Download RAW message or body]

On Wednesday 13 November 2013 20:58:46 you wrote:
> Not only the "source materials" need to be accessible without additional
> third party account, but everything that is needed for participation.
> 
> Example: Let's say KDE project KoolApp has a TODO list on a third party
> website with invasive privacy policies. Then we can have two cases:
> a) Developers are expected to read this TODO before doing bigger changes to
> the code, so that they do not interfer with the plans of others. This would
> de facto create a problematic barrier for participation (agreement to
> privacy- hostile third party contracts). The wording "project asset" would
> cover the case, but "source materials" would not.
> b) The TODO list serves as an inoffical reminder document for the two lead

I think you're correct in your observation, but I don't
think it's a problem. Basically, one of the problems we
had with software / project assets is actually whether
it would read on todo lists on Trello, because we don't
want it to, because it's too restrictive.

Now, it's entirely correct that this allows projects to
make todo lists hard to access and contribute to - but
if they do that, they're shooting themselves into their
own feet, because they're making participation in work-
ing on the source materials (which the Manifesto "pro-
tects") difficult. So there's already a pressure acting
on projects to make todo lists easily accessible, mean-
ing we IMHO don't need to regulate that behavior in the
Manifesto.

That doesn't mean people won't ever be stupid and try
to put todo lists onto a crappy service, but then some-
one will complain, and it'll hopefully get fixed.

This page in the Manifesto is about the bar that pro-
jects need to meet to be considered KDE projects, and
I think in that context we care about the source ma-
terials instead of writing down how folks must behave
in the process of working on them. That's more a quest-
ion of social etiquette.


> Olaf

Cheers,
Eike
_______________________________________________
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
[prev in list] [next in list] [prev in thread] [next in thread]