#26 Privacy_Statement_Draft

Merged
meaz merged 30 commits from Privacy_Statement_Draft into master 1 year ago
fede commented 1 year ago
Owner

Final draft.

Final draft.
fede added this to the 1.2 milestone 1 year ago
antilopa was assigned by fede 1 year ago
fede self-assigned this 1 year ago
meaz was assigned by fede 1 year ago
muppeth was assigned by fede 1 year ago
maryjane was assigned by fede 1 year ago
fede added the
PRIVACYSTATEMENT
label 1 year ago
fede added the
REVIEW
label 1 year ago
muppeth commented 1 year ago
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 1 year ago
fede added the
UPDATE
label 1 year ago
muppeth reviewed 1 year ago
privacy_policy.md Outdated
muppeth commented 1 year 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 1 year ago
privacy_policy.md Outdated
muppeth commented 1 year 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)
muppeth commented 1 year ago
Owner

Still missing the piece about english version taking precendence.

Still missing the piece about english version taking precendence.
muppeth reviewed 1 year ago
privacy_policy.md Outdated
muppeth commented 1 year 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 1 year ago
privacy_policy.md Outdated
antilopa commented 1 year ago

maybe "which we can be held responsible for"?

maybe "which we can be held responsible for"?
antilopa reviewed 1 year ago
privacy_policy.md Outdated
antilopa commented 1 year 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 1 year ago
privacy_policy.md Outdated
antilopa commented 1 year ago

actualy it should be - Stichting Disroot.org

actualy it should be - Stichting Disroot.org
antilopa reviewed 1 year ago
privacy_policy.md Outdated
antilopa commented 1 year 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 1 year ago
privacy_policy.md Outdated
muppeth commented 1 year ago

👍

👍
meaz reviewed 1 year ago
privacy_policy.md Outdated
meaz commented 1 year ago

it seems perfect to me

it seems perfect to me
meaz approved these changes 1 year ago
muppeth approved these changes 1 year ago
muppeth left a comment

👍🎉🎉🎉

muppeth commented 1 year ago
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 1 year 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.

antilopa commented 1 year ago
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?
muppeth commented 1 year ago
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 1 year ago
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.
antilopa commented 1 year ago
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.
muppeth commented 1 year ago
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 1 year ago
Owner

Fine with me.

Fine with me.
antilopa commented 1 year ago
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.
antilopa commented 1 year ago
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.
muppeth commented 1 year ago
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 1 year ago
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 1 year ago
muppeth commented 1 year ago
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)
muppeth commented 1 year ago
Owner

Added version number

Added version number
fede commented 1 year 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
antilopa commented 1 year ago
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 1 year ago
muppeth commented 1 year ago
Owner

@antilopa I would say remove it from this document

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

Muppeth approves this merge

meaz approved these changes 1 year ago
muppeth commented 1 year ago
Owner

![](https://i.imgflip.com/297nvg.jpg)
antilopa approved these changes 1 year ago
meaz closed this pull request 1 year 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.