#26 Privacy_Statement_Draft

Merged
meaz merged 30 commits from Privacy_Statement_Draft into master 10 months ago
fede commented 11 months ago
Owner

Final draft.

Final draft.
fede added this to the 1.2 milestone 11 months ago
antilopa was assigned by fede 11 months ago
fede self-assigned this 11 months ago
meaz was assigned by fede 11 months ago
muppeth was assigned by fede 11 months ago
maryjane was assigned by fede 11 months ago
fede added the
PRIVACYSTATEMENT
label 11 months ago
fede added the
REVIEW
label 11 months ago
Poster
Owner

We should add link to the GIT Repository (commit page of master) with information that people can check version history of the document.
Also we should add 1.2 tag on the merge.

We should add link to the GIT Repository (commit page of master) with information that people can check version history of the document. Also we should add 1.2 tag on the merge.
fede added the
1.2
label 11 months ago
fede added the
UPDATE
label 11 months ago
muppeth reviewed 11 months ago
privacy_policy.md Outdated
muppeth commented 11 months ago

I would rather remove the first sentence:
"
All and any changes to the Privacy Statement will be publicly available and will be communicated to all users via our social networks and blog bosts.
We recommend that you regularly check for any changes on this Statement.
"

I would rather remove the first sentence: " All and any changes to the Privacy Statement will be publicly available and will be communicated to all users via our social networks and blog bosts. We recommend that you regularly check for any changes on this Statement. "
muppeth reviewed 11 months ago
privacy_policy.md Outdated
muppeth commented 11 months ago

ou can follow the history of changes on this document on our git repository version control system here

ou can follow the history of changes on this document on our ~~git repository~~ version control system [**here**](https://git.disroot.org/Disroot/Disroot-Privacy-Policy/commits/branch/master)
Poster
Owner

Still missing the piece about english version taking precendence.

Still missing the piece about english version taking precendence.
muppeth reviewed 11 months ago
privacy_policy.md Outdated
muppeth commented 11 months ago

"This ducument has been written originally in English by Disroot.org "core team" and is the only text version for which we are responsible for.

"This ducument has been written **originally** in English by Disroot.org **"core team"** and is the only text **version** for which we are responsible **for**.
antilopa reviewed 11 months ago
privacy_policy.md Outdated
antilopa commented 11 months ago

maybe "which we can be held responsible for"?

maybe "which we can be held responsible for"?
antilopa reviewed 11 months ago
privacy_policy.md Outdated
antilopa commented 11 months ago

also "core team" is a bit vague and can change, i think leaving it as Disroot.org - the organization - is more professional.

also "core team" is a bit vague and can change, i think leaving it as Disroot.org - the organization - is more professional.
antilopa reviewed 11 months ago
privacy_policy.md Outdated
antilopa commented 11 months ago

actualy it should be - Stichting Disroot.org

actualy it should be - Stichting Disroot.org
antilopa reviewed 11 months ago
privacy_policy.md Outdated
antilopa commented 11 months ago

"This document has been written originally in English and is the only version for which stichting Disroot.org can be held responsible." (or accountable also sounds good)

"This document has been written originally in English and is the only version for which stichting Disroot.org can be held responsible." (or accountable also sounds good)
muppeth reviewed 11 months ago
privacy_policy.md Outdated
muppeth commented 11 months ago

👍

👍
meaz reviewed 11 months ago
privacy_policy.md Outdated
meaz commented 11 months ago

it seems perfect to me

it seems perfect to me
meaz approved these changes 11 months ago
muppeth approved these changes 11 months ago
muppeth left a comment

👍🎉🎉🎉

Poster
Owner

One more thing that caught my attention before we merge (glad @antilopa didnt approve it yet).
I think we didnt look into layout of the page. Seeing that the breakline is right after TOC and I think none of the points actually link to TOC so cant navigate using it.
Also line break in this template means to start second column so we will have currently only TOC on the left side and entire document on the right side which i think is not whatwe wanted to do.
@antilopa can you move this file to the website vagrant and check it?

One more thing that caught my attention before we merge (glad @antilopa didnt approve it yet). I think we didnt look into layout of the page. Seeing that the breakline is right after TOC and I think none of the points actually link to TOC so cant navigate using it. Also line break in this template means to start second column so we will have currently only TOC on the left side and entire document on the right side which i think is not whatwe wanted to do. @antilopa can you move this file to the website vagrant and check it?
muppeth requested changes 11 months ago
muppeth left a comment

We need to check the layout of the page to make sure its correct and that TOC links to all the points in the document.

Poster
Owner

@muppeth you are right, the horizontal line in the template of the PP seperates the two columns. But I think if we get the text right here in this repo, it is enough. The layout will be something to figure out when merging it in the website repo. Don't you think?

@muppeth you are right, the horizontal line in the template of the PP seperates the two columns. But I think if we get the text right here in this repo, it is enough. The layout will be something to figure out when merging it in the website repo. Don't you think?
Poster
Owner

@antilopa well it depends what we want.

  1. If we have both files same its easier to make checksum of the file to be sure the text is correct and not tempered with (could even have set alert on that)

  2. If the document is only to see history, we should then remove the markdown grav header and all the other markdown formating so its easier for people to read.

  3. Same as point 2 but with md formatting still there but without the grav header

@antilopa well it depends what we want. 1. If we have both files same its easier to make checksum of the file to be sure the text is correct and not tempered with (could even have set alert on that) 2. If the document is only to see history, we should then remove the markdown grav header and all the other markdown formating so its easier for people to read. 3. Same as point 2 but with md formatting still there but without the grav header
meaz commented 11 months ago
Poster
Owner

How will things work? I mean, each change will be made in this repo, then merged in Website repo?
If this is the case, I think 1st solution of muppeth is better. Otherwise, that means that each time we change something here, we have to update the Website version manually.

How will things work? I mean, each change will be made in this repo, then merged in Website repo? If this is the case, I think 1st solution of muppeth is better. Otherwise, that means that each time we change something here, we have to update the Website version manually.
Poster
Owner

I don't really get it. Any changed made should always be updated on the website. We are not pulling this repo directly into grav are we?

Secondly, the PP is not only for the website, some services has their own place for PP. And what if we decide to change the layout on the website?

I think this repo should be for version control, and can be stripped of most MD, unless useful here. checksum would be nice but wouldn't work in this case.

I don't really get it. Any changed made should always be updated on the website. We are not pulling this repo directly into grav are we? Secondly, the PP is not only for the website, some services has their own place for PP. And what if we decide to change the layout on the website? I think this repo should be for version control, and can be stripped of most MD, unless useful here. checksum would be nice but wouldn't work in this case.
Poster
Owner

yeah so we seem to have unsolved issue here then. Specially that I agree with all two ideas.

Maybe indeed to make things easier at least for now, we should keep this repo as a non markdown version, so just plain text, which would be easier for people to ead through and in case we need to copyt PP elsewhere (same goes for TOS), we dont need to strip it from markdown (in case we need to do for example html as is in pwm). This also makes it easy for people to read and follow rather then going through the markdown syntax.

Just to push things forward as it's taking way too long now, I would suggest this and then in the future if we think this isnt working right, change it to be exact copy of the website's page.

yeah so we seem to have unsolved issue here then. Specially that I agree with all two ideas. Maybe indeed to make things easier at least for now, we should keep this repo as a non markdown version, so just plain text, which would be easier for people to ead through and in case we need to copyt PP elsewhere (same goes for TOS), we dont need to strip it from markdown (in case we need to do for example html as is in pwm). This also makes it easy for people to read and follow rather then going through the markdown syntax. Just to push things forward as it's taking way too long now, I would suggest this and then in the future if we think this isnt working right, change it to be exact copy of the website's page.
meaz commented 11 months ago
Poster
Owner

Fine with me.

Fine with me.
Poster
Owner

I almost agree :P I think there is a value to some MD so it is nicely formatted and easy to read here too. But I will keep it to a minimum - meaning mainly headers and lists.

I almost agree :P I think there is a value to some MD so it is nicely formatted and easy to read here too. But I will keep it to a minimum - meaning mainly headers and lists.
Poster
Owner

After talking about this a bit more I'm finally convinced about the @muppeth's first option. It means we will not have a PP page on the website but it will be pulled for this repo. Then the content cannot be changed without enough approval which is good.

That said, we now need to check the layout on the website and adjust the file here to look right before we can merge it. We also need to figure out the file naming (on the website it is two-col.html.twig) and other practicalities.

After talking about this a bit more I'm finally convinced about the @muppeth's first option. It means we will not have a PP page on the website but it will be pulled for this repo. Then the content cannot be changed without enough approval which is good. That said, we now need to check the layout on the website and adjust the file here to look right before we can merge it. We also need to figure out the file naming (on the website it is two-col.html.twig) and other practicalities.
Poster
Owner

And the practicalities would be adding gitignore file on pages repo to not pull privacy policy etc. so bacially we would be pulling directly from here. If so, does that also apply to TOS repo? it should.

And the practicalities would be adding gitignore file on pages repo to not pull privacy policy etc. so bacially we would be pulling directly from here. If so, does that also apply to TOS repo? it should.
meaz commented 11 months ago
Poster
Owner

Yes, I think we should do the same with TOS repo

Yes, I think we should do the same with TOS repo
muppeth approved these changes 10 months ago
Poster
Owner

Changed retention of XMPP to 1 month; removed Diaspora; fixed lists to use '-' instead of numbers everywhere (for consistency sake)

Changed retention of XMPP to 1 month; removed Diaspora; fixed lists to use '-' instead of numbers everywhere (for consistency sake)
Poster
Owner

Added version number

Added version number
fede commented 10 months ago
Poster
Owner

Removed Diaspora* from the federated services examples at the definitions section

Removed Diaspora* from the federated services examples at the definitions section
Poster
Owner

Last checks on vagrant before final approval:

  • file should be named fullbar.en.md
  • Title is now duplicate. two options: we take it out of this text and adjust it in the title of the webpage or remove the title bar in web page.
  • #top anchor is missing
  • anchors are generally a bit off (titles hide behind the navbar) but we can fix this maybe later
Last checks on vagrant before final approval: - file should be named fullbar.en.md - Title is now duplicate. two options: we take it out of this text and adjust it in the title of the webpage or remove the title bar in web page. - #top anchor is missing - anchors are generally a bit off (titles hide behind the navbar) but we can fix this maybe later
antilopa approved these changes 10 months ago
Poster
Owner

@antilopa I would say remove it from this document

@antilopa I would say remove it from this document
muppeth approved these changes 10 months ago
muppeth left a comment

Muppeth approves this merge

meaz approved these changes 10 months ago
Poster
Owner

![](https://i.imgflip.com/297nvg.jpg)
antilopa approved these changes 10 months ago
meaz closed this pull request 10 months ago
The pull request has been merged as ac3756f89a.
Sign in to join this conversation.
No reviewers
No Milestone
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.