Hi,
intrigeri:
> spriver:
>> the Tails Project wants to have a social contract […]
>
>> Now we want your help and want to hear your opinion: feel free to
>> comment and/or edit the draft, be encouraged to discuss it on the ticket
>> or as an answer to this mail.
>
> Here we go! Amazing work, thanks :)
>
>> Through our community standards and the code we write and deploy, we
>> provide tools that empower all people
>
> I'd rather not reduce what we collectively produce to "code".
> How about:
>
> Through our community standards, the tools we build, document,
> translate and promote, we provide tools that empower all people
much better indeed.
>> and advance these rights.
>
> I have two concerns with this:
>
> * The text doesn't make it clear to me which rights this refers to.
"these rights" refers to "privacy, the free exchange of ideas, and equal
access to information".
> * I'm no big fan of the "rights" idea, but we can perhaps agree on
> something once the above is clarified.
>
> Just dropping this piece of text doesn't seem to lose anything IMO: we
> already have "empower all people".
I think dropping it is possible, but this part of the sentence wants to
provide more detail on what kind of tools we produce. That is, tools
which advance these ideas, which are a necessity for a free and open
society. For now, I've replaced "rights" with "concepts".
>> Tails will always be free to use, remix, adapt and distribute.
>
> I think we should not ignore the exception we make for firmware here,
> and try to be upfront about it, e.g. as we tried to do on our License
> page: https://tails.boum.org/doc/about/license/
I agree and added the same sentence.
>> When we write new components of the Tails system, we will license
>> them in a manner consistent with the Debian Free
>> Software Guidelines.
>
> In there, "new" suggests to me that there have been exceptions in the
> past. Are there any? If not, let's be clearer and instead write: "All
> the components of Tails that we create ourselves are, and will be,
> licensed in a manner […]".
ack
>> work on usability issues which we include in Tails
>
> Seems that there's a few words too few or too many in here, no?
not at all. But I think indeed that the sentence is a bit hard to read.
So i deleted "which we include in Tails" as this seems obvious enough.
>> Mistakes sometimes happen. We will be honest about them and fix them
>> when they are reported to us.
>
> I wonder if "when" is too vague or too precise here. On the one hand
> it suggests we promise to correct every mistake we make (which seems
> impossible to me, or just a bad idea, as pretty often we have other,
> higher priority things to do); on the other hand it is very vague wrt.
> the timing, and doesn't promise much in the end, which may make the
> text a bit weak, particularly wrt. mistakes that affect users' safety.
>
> So I wonder if we could perhaps be more precise, and make a stronger
> commitment, about a better defined set of mistakes, i.e. those that
> affect the safety of Tails users.
>
> What do you think?
We had the discussion quite some time during the initial set up of this
contract and decided that that's good enough. But the questions you
raise were ours equally and I think your proposal would be a good solution.
>
>> 5. We will not hide problems
>>
>> Our entire bug report database is and will stay open for public view
>> at all times. Reports that are filed here will promptly become
>> visible to others.
>
> I'm not sure we can reasonably promise this. Currently, a great part
> what qualifies as "bug reports" filed to us is sent to our help desk,
> and only some of that is published; e.g. I'm pretty sure that many
> problems experienced by Tails users never make their way to Redmine,
> because our help desk deems them not important enough to be worth
> fixing. Also, our help desk is researching a Request Tracker tool
> they'll use, and I bet that some of its content might qualify as
> a subset of "Our entire bug report database".
>
> Taking a step back, what matters most *to me* about the "we will not
> hide problems" statement is not claiming that we're aiming for full
> transparency, for two reasons: first, I'm not sure we can easily agree
> about this being a worthy goal, ideologically speaking, within the
> project; second, this would require spending lots of energy to
> sanitize and publish lots of information that won't be very useful to
> anyone; third, the next paragraph states that there are exceptions
> anyway so it'll never be full transparency.
>
> What matters to me is rather:
>
> * Except when some kind of responsible disclosure is deemed best for
> our users, we will not *actively* hide problems that affect Tails
> users, e.g. we won't be dishonest about our mistakes and the limits
> of Tails. This is already kinda covered in the paragraph about
> mistakes earlier, and in the next statement about honesty.
> So perhaps we don't need additional text to state this.
>
> * We want to produce Tails in a way that encourages participation,
> which requires publicly documenting what can be improved. This is
> somewhat off-topic in a section titled "We will not hide problems",
> so I suggest we create a new section about how Tails is produced,
> that would include this bit and the "As Tails is created in
> a transparent manner […]" that feels slightly out of place in the
> "4. We will never harm our users intentionally" section.
I modified this part quite a bit. Please review.
>> 6. We are honest about the capabilities and limits of Tails and
>> related technologies
>
> I think that "related technologies" is way too broad. How about
> "technologies it relies upon" instead? This is what matters, right?
great idea.
>> fits their security needs
>
> This feels unnecessary after "adequate for their use case", so I would
> drop it.
ack.
>> whether it can and should be trusted
>
> I would prefer the active voice, a phrasing that doesn't suggest
> there's a universal (sic) answer to this, and a concept of trust
> that's not binary, e.g.:
>
> We encourage users to inform themselves and decide whether Tails is
> suitable for their use case and how much they can trust it.
very good.
>> We provide and explain methods of verification so that anyone can
>> ensure that they downloaded a genuine copy of Tails.
>
> This feels out of place in a section titled "6. We are honest about
> the capabilities and limits of Tails and related technologies".
> I'm not sure why mentioning this specific security feature of the
> Tails ecosystem (and not any other such feature) is very relevant in
> our social contract.
I think we basically wanted to extend the paragraph about trust. And
through reproducible ISO images in the future and currently verification
methods we want people to be able to trust what they downloaded.
I agree, this might not be the right place to say this.
And even, that this sentence might not eben have to be in the contract.
For now, i left it in there, until further discussion.
Cheers!
u.
