search

karrot-dev / karrot-frontend

We migrated to https://codeberg.org/karrot/karrot-frontend
https://codeberg.org/karrot/karrot-frontend
429 stars 177 forks source link

Accept agreement before joining the group #324

Closed tiltec closed 4 years ago

tiltec commented 7 years ago

UPDATE lastest proposal in https://github.com/yunity/karrot-frontend/issues/324#issuecomment-405231132

Additional backend field and checkbox required.

tiltec commented 7 years ago

Random scribblings about this:

it's allowed to have groups without agreement group member sets/changes agreement text new members have to agree before they can join the group

questions:

  1. if agreement changes, does everybody have to agree again?
  2. who can change the agreement?
  3. what happens to members who joined before the agreement was online?
  4. do we need an overview page "who agreed to the agreement"?
  5. can members also withdraw their agreement later?

idea: make legal agreement immutable

D0nPiano commented 7 years ago

I like the idea and your random scribblings

  1. I think it's be best if everyone had to agree again. It's simple and the most "natural" way of doing it.
  2. Mhm, since we don't have roles... anyone then? That's a very tough one though
  3. related to 1 - they have to agree again
  4. I don't think we need one. I think it would make sense if people who did not agree could not perform any action in that group though (not beeing able to join pickups etc.)
  5. If you couldn't perform any action when you didn't agree anyways, you could also just leave the group to disagree

Making the agreement immutable solves 1, 2 and 3. But I think only 2 is really problematic. Therefor, I am for beeing able to change it, I'm just unsure whether everyone should be able to, or only the group-creator. I think best would probably be some other admin way (...reminds me of my thoughts of a Trust System I never really finished)

stefan-fstaiwan commented 7 years ago

There should be basic guidelines people have to agree on before they get an account in fstool... basically telling them that we are dealing with food, which means that there might be the risk of harming people and by signing in people basically agree in taking the risk on their own. Also making clear that when they want to pick up food from stores they must agree on a legal contract. For people who want to share food p2p or through public fridges it is difficult to control any legal statement, but for people who do the pick ups it will actually be necessary. Most food retailers demand it! As the legal situations on food vary from country to country I guess we have to go by groups... maybe every group should have an imprint with information on the legal status. Some retailers might ask for stricter requirements then others... nevertheless I think it might be dangerous to have groups without any legal statements.

  1. yes
  2. No roles yet? Longterm there could be someone like "Betriebsverantwortlicher"
  3. I think at some point there should be some kind of a restart of the website, so that people have to agree
      1. agree with D0nPiano

I think having basic guidelines every user has to agree on would already help with many of this. It would be a immutable agreement, while the legal agreements of each group expand on that.

tiltec commented 7 years ago

(Discussion here with @djahnie and @nicksellen)

  1. The legal agreement should be optional and per-group, decided by group admins
  2. We need some people (group admins) in the group who are able to edit the legal agreement -> #356
  3. If the legal agreements gets changed, all members have to accept again (simpler implementation) 3.1 If users are already in the group and have not accepted the latest agreement, they should be showed a dialog and be prompted to agree on it. 3.2 If users join a group, joining and accepting should be done in one step

Probably we could record the date when the users agreed, so we could later compare it to the change time of the agreement.

@stefan-fstaiwan

basic guidelines that people have to agree on before they get an account in fstool

I fully agree, though it seems separate from this topic and we should perhaps split the discussion. I added it as an idea on the roadmap: https://github.com/yunity/foodsaving-frontend/blob/master/ROADMAP.md#ideas--brainstorming

Sliverriver commented 7 years ago

there must be a difference between the legal agreement you would necesarly have in running the site or an agreement that would be closer to "real life" and paper based. maybe it is best to differenciate between this.

unfortunately due to experience with admin roles on foodsharing and the dependencies within the misuse is bigger then the actual benefit.

stefan-fstaiwan commented 7 years ago

@Sliverriver Must there be a difference between these both? At the moment I use a paper based legal agreement here in Taiwan, but if the community gets bigger I have no idea how to manage this. Right now I'm meeting people before they are allowed to pick-up and make them sign on a paper... but that's actually very strenuous. So I'm wondering how we want to deal with that for the foodsaving tool. Is it already legally binding if users accept it online? That's how is works on foodsharing.de doesn't it? But maybe that's also different from country to country. I think the target should be to make people accept the legal agreement online... cause there is no way to meet all of them in person for signing. After that everybody who signed will get a member (ID) number, which will be used together with the name to generate an ID card. So ID can be send after the legal arrangment was signed. For our team here in Taiwan that's a crucial issue that has to be solved before we can use the foodsharing tool. As long as the community is small it might still be possible to meet people in person to make them sign. So a simple idea to handle this for the moment would be, that the legal arrangement can be added as link to the discription of a groups. So at the end of that document it will tell the person that he/she will need an ID before she will be able to get into the group. To get the ID she will have to send an email with name and photo to our email adress (that's how we do it already) and meet me or another member to sign the contract... after that she will get an email with her ID and the password for the group.

@tiltec Is it this one "Set up a legal entity for foodsaving.world, add terms of service"? Actually as more as I think about it, as more important it becomes to me to have general guidelines for everybody. They should be aware that we are dealing with food, which means that there might be the risk of harming people and by signing in people basically agree in taking the risk on their own. Also making clear that when they want to pick up food from stores they might need to agree on a legal contract. Basically the "Grundverständnis" of foodsharing.de https://wiki.foodsharing.de/Foodsaver#Grundverst.C3.A4ndnis

tiltec commented 7 years ago

Thir issue is about a text that users have to accept before they can join the group. The text should be customizable per group. Is that what you need? @stefan-fstaiwan

If you need something else, can you open another issue? e.g. for a text that users have to accept before signing up to foodsaving.world.

stefan-fstaiwan commented 7 years ago

@tiltec We basically just can allow people to pick up food, after they have signed a legal arrangement. So my question is, how do we want to incorporate this function into the foodsaving tool. Is people accepting a text online enough to be legally binding (I guess that's more a legal rights matter). If someone gets sick, I think if this person signed a paper, that somehow counts here in Taiwan, but I'm not sure about accepting something online.

There is no need for a text that needs to be accepted before signing up to foodsaving.world... it's more a note, showing the "Grundverständnis" of the project. I can open a another issue for that.

tiltec commented 7 years ago

foodsharing.de has two steps: first, you accept the legal agreement online and second, an ambassador will verify your ID card in person. Only then you will be able to pick up food. Should we copy the same principle for groups in the foodsaving tool?

Sliverriver commented 7 years ago

there are distinctions to be made - the first one is the Tos ( Terms of services?) and the "data privacy statement" - this is something that is needed for everyone who signs up for a site and the site owner is responsible for it. So there is no way to "not have" it . "something" must be there.

This should be clearly distinguished from the "second" one, that is implemented in foodsharing right now. Unfortunately with everything people sign up and read online - people don't read it. Making it kind of useless. That is the experience we have from fs.de . There are some important information in it that people should be aware of - like check your insurance for volunteer work - etc. But people don't read it. Just click it. Since it is a different situation for different groups that might be more handled in real life.

So if it is considered an "important document that people should be aware of" maybe offline signing and documenting should be preferred.

I do like the approach of reconsidering and questioning why are we doing this or that on fs.de and if it is still usefull - or what turned out to be harmfull. (Having users with to much administrativ power (ambassadors) for example).

tiltec commented 7 years ago

This issue is not about ToS and privacy statement. Please open another issue about them.

stefan-fstaiwan commented 7 years ago

Good point Kristijan!

So we agree that there must be some kinds of "Terms of services"... whatever they will look like. We will discuss it in another issue.

Maybe one option could be to make the group admin ("oldest") to help with the offline signing of a legal agreement:

A the legal agreemet can (optional) be added as link to the discription of a group. The description will also tell the Foodsaver that he/she will need an ID before he/she will be able to get into the group and for that he/she has to sign the legal agreement first. Then there will also be the contact of the group admin. So the Foodsaver will have to meet the group admin to sign on paper and afterwards send him/her and email with name and photo. As soon as the group admin gets this email and the legal agreement is signed, he will forward this email plus the group password to an ambassador to create an ID. The ambassador will send an email with ID and group password to the Foodsaver.

Sounds more complicated than it is.... but I'm also happy to hear better options :-)

tiltec commented 7 years ago

To do offline verification, maybe the upcoming #380 Invitations could be helpful:

Regarding admins, there's this proposal #550. Would be happy about your input there @stefan-fstaiwan

nicksellen commented 7 years ago

If someone gets sick, I think if this person signed a paper, that somehow counts here in Taiwan, but I'm not sure about accepting something online. @stefan-fstaiwan it would make sense to resolve this question first - depending on the outcome the feature we are discussing here may or may not be useful for you.

if it is not possible to find out, or you want to start operating with paper legal agreements immediately, then the process suggested by @tiltec should be sufficient for now (even if not perfect). I started a discuss about closed groups in #566).

tiltec commented 7 years ago

@Sliverriver commented in #550, though it seems more appropriate here:

i would like to take a step back -

how do we now if it is anything "legal" or binding"

it could be a text like "You accept me as your lord and master and must do as i say". or "if you accept this then you own me a cake! you willingly agree to this condition! "

It can never be evaluated if whatever text people are writing is legally appropriate or even valid.

So it is the featuer of a "welcome message that you either agree or decline"- declining making it unable for the user to join the group.

that would be the feature description.

Whatever the content is the user decides, but whoever is running the tool doesn't take any legal ownership / responsibility of the content of that message. and you could name it "friendship agreement, or "legal agreement" or whatever name you want or your imageniry lawyer tells you to.

maybe it would be usefull to avoid terms like "legally binding","terms of service", etc. that sound highly official and approved of some legal entity or including any kind of responsibility from the site owner.

My proposed description text would be:

"terms you have to accept before you can join the group"

and the field's name could be

"group terms"

What do you think?

Sliverriver commented 7 years ago

do you mean with description text - the text that would appear above an edit box for user entry? and is field name the name of the field for the description of the "terms"? i am not sure if a disclaimer might be usefull - something like - oh this is made by a user and not by the tool in any way - we don't care. it's just a feature.

e.g.: 1) Disclaimer: "You have to agree to this text, before you can join the group. This text solemny is in responsible of the group and doesn'T represent views regulations or oppinions of the tool hosting site". group Terms : "Rules of my kingdom" Text: "this is my kingdom - you must do as i say. if you don't feel comcortable with it, please don't join". 2) Disclaimer: "You have to agree to this text, before you can join the group. This text solemny is in responsible of the group and doesn'T represent views regulations or oppinions of the tool hosting site". group Terms : "Terms & Conditions of foodsaving Taiwan" text : " You hearby swear to uphold the law and do no shit wrong".

tiltec commented 7 years ago

Yes, it should be clearly marked as user-provided text, similar to the public group description. I would like to find a nice graphical solution, but if that's not enough, we can still add a "disclaimer" text as you proposed.

Sliverriver commented 7 years ago

another question : If the "text" for the group terms change, does every person have to agree again when they log in next time - or leave the group.

i am not sure if the same data model can be used to solve #607

only difference - this one the group set's the text and the other one the "site owner" "installer?" set's it.

nicksellen commented 7 years ago

another question : If the "text" for the group terms change, does every person have to agree again when they log in next time - or leave the group.

Yes, scroll up to https://github.com/yunity/foodsaving-frontend/issues/324#issuecomment-312685256 ;)

nicksellen commented 7 years ago

i am not sure if the same data model can be used to solve #607 only difference - this one the group set's the text and the other one the "site owner" "installer?" set's it.

It's quite different, so I would not intertwine them. It is fine to get the group terms feature ready to use without having to depend on whole-site terms feature.

tiltec commented 6 years ago

(Originally written by Nick, moved from https://github.com/yunity/karrot-backend/issues/385)

So https://github.com/yunity/karrot-backend/issues/417 implements the most basic features in the backend that is mergable, still not addressed are:

Two things I think I don't need to implement (at least right now) are:

djahnie commented 6 years ago

I just received feedback from Unai in Bilbao, that they'd also very much appreciate it to have legal agreements directly inside Karrot. That's his original message:

It would be great if the liability contract could be signed online when you first sign up in Karrot 🙂

Since there is so much to consider with this topic I then linked him to this issue and will hopefully soon get more detailed insights about what he expects.

nicksellen commented 6 years ago

Hopefully the agreements stuff implemented is sufficient for setting it, but two aspects are not really worked out yet:

djahnie commented 6 years ago

This goes back to discussion about the questions @nicksellen raised above.

tiltec commented 6 years ago

As soon as we have user levels as outlined in #1062, we could make it so that full members (UL3) get the right to edit the agreement.

Later on, we could have voting process to become agreement_manager.

what should be restricted if members have not agreed

There seem to be different, possibly conflicting requirements:

I would propose the following solution: as part of the group approval process #894, applicant would explicitly agree to the terms. Only by doing so, they can send their application to the group.

If the agreement changes, the first implementation step could just show the red banner but have no repercussions for people who didn't agree. It should be visible who didn't agree yet in the member list (or in some other place), to allow for some social pressure. Later on, we could implement an automated removal from the group after 30 days of having not-accepted agreements.

Ping @djahnie @nicksellen for input :)

djahnie commented 6 years ago

Sounds good!

Especially the explicit agreement during the application process and the automatic removal after a certain period of time, in case the agreement changes. I'm just not sure if 30 days are maybe not too much. I mean, if this is actually about legal issues, it could be that sometimes immediate action is required, so I'd reduce the time frame to 14 days, send out an email notification and block the person from joining pickups until they accepted the modified agreement.

(I'm simply not thinking about malicious usage right now, because if an editor wants to fuck with the foodsavers then the group is going to shit anyways... Sorry for the language... :sweat_smile:)

nicksellen commented 6 years ago

Some related discussion from the forum https://community.foodsaving.world/t/legal-agreements/75

tiltec commented 6 years ago

With the trust system of https://github.com/yunity/karrot-frontend/pull/1077 in place, this could be revived. For example, to grant the agreement manager role when user became editor or when they reached a higher trust threshold.

tiltec commented 6 years ago

We could enable the agreements feature quite easily if we wanted to - should we do it?

djahnie commented 5 years ago

We apparently won't enable it anytime soon and will now wait until we feel that its time has come. That could be when we have polished our issues concept so that it also serves the purpose of electing people for specific roles like the agreement manager. Until then it just lays around and is not in the way.

tiltec commented 5 years ago

FYI: with the Quasar v1 upgrade, I probably broke the agreement frontend. But I didn't check.

github-actions[bot] commented 4 years ago

This issue is marked as stale because it has not had any activity for 90 days, remove the stale label or add a comment on it, otherwise it will be automatically closed in 7 days. Thanks!