Thanks for posting this initiative! Removing the need to maintain a separate registration flow/software would be good if possible.

Some questions:

• how does the current flow work?

• how would the new flow work?

  • specifically how would things change for the Community Working Group Ops Team, who I believe currently process registrations.

Also I think 3 days may be too short for this poll - according to the terms, at least 6 days is needed (I wouldn't consider this change as urgent).

Just to follow up on my vote comment (which got restricted in length):

I think the starting point for this is a discussion with the community working group people. I mentioned on the call we tried this before, and it didn't work out.

And the relevant bit from the terms is:

Working groups are encouraged to make proposals among themselves to determine consensus and operate within their scope of responsibility, but only proposals passed by the full group may be considered binding for Social.coop. Any member may make a proposal to the full group, though it is encouraged to first discuss matters within the appropriate working group.

Hi! I don't understand what didn't work out here :)

I read that paragraph as being centered around "considered binding". Of course the tech working group couldn't vote at their scope and decide on this and have that decision be binding. But I don't see anything wrong with starting a proposal at a greater scope and have the discussion with the working group owning this (community) while we all vote and get information for steering the discussion in the process?

I respectfully posit that removing steps towards collaboration is usually a good idea at least by default, and in particular when one moves towards greater inclusiveness while doing so (as we presumably did in this case by putting it to a general vote) so I currently stand behind this "experiment" :)

Thanks for the initiative @Flancian! I think if we did this, we would end up pointing folks to a separate form anyway to collect information such as the OpenCollective profile. Unless Mastodon lets us customize the information collected during the sign-up flow, I'm not sure we'll gain much from switching to the native flow.

This is basically my question -- can you customize the fields of the sign up form to mirror the current sign-up? I have had friends interested in the instance that didn't join because they couldn't figure out the process and were turned off. If not, it seems like something relatively straightforward that we could implement in our fork (presuming we run on a fork?). It looks like there already is an `invite_request_fields` array in the `.haml` for account registrations: https://github.com/mastodon/mastodon/blob/c3aef491d66aec743a3a53e934a494f653745b61/app/views/auth/registrations/new.html.haml#L31-L34 and https://github.com/mastodon/mastodon/blob/87a55e2cd67a2af754f5a80282635e789c255e72/app/views/about/_registration.html.haml#L19-L22

In either case I'm pro this proposal, making our registration flow as similar as possible to other instances is good for both entrance into our own instance as well as the broader health of other masto instances: in general, when possible, I think if mastodon doesn't support some feature that we need, like specific mod flow to approve accounts, special fields, etc. then we should work to PR those into mastodon itself rather than make side channels.

it's not possible to customize the fields (last time I looked anyway). we don't run a fork, we simplified the tech setup as much as possible, as it's been hard to keep tech motivation high enough to keep up with updates.

it would be super to have the multiple field approval thing, I think that would be well supported by social.coop people, the question is more who would do that, and in a way to make sure we can still manage to do updates (that's kind of the bare minimum needed to keep running properly).

as I mentioned in another comment, @Akshay had mentioned the idea to find/create an issue in upstream mastodon. and it's probably best started as a discussion there, rather than code first and hope they accept.

@Nick Sellen what would satisfy your urge to block? Should we arrange a meeting between working groups?

And it is true that final confirmation of a decision like this should happen at large, rather than in a working group.

Thank you @Nathan Schneider , @Nick Sellen for your feedback! I've changed the duration of this poll from an insufficient 3d to 12d (double the recommended minimum). Apologies for not following procedure -- I did think 3d seemed short but that was the default suggested by Loomio. I wonder if it can be changed? On a meta level I think it would be a good idea to reduce friction for new proposals, and setting better defaults for the group (if feasible) seems like good bang for the buck.

In any case, I want to clarify that I started this thread and the proposal to gather feedback and get a quick pulse of what the community thinks+feels; I don't know the established procedures and their history enough to say "what we're doing is wrong", they just seemed improvable at low cost so I thought I'd give it a shot :)

Finally, I've invited the wider community to vote -- this is not limited to the tech group, and I agree of course it shouldn't be.

@Nathan Schneider / @Flancian thanks for extending the time.

so my main point remains that the topic of registrations is in the scope of the community working group as they actually do they work there. it's easy to flick the switch in the interface to "approval required" registrations, but then it changes the work that is required for other people, so without consulting the people that do the work, or including considerations for how their work changes, I don't really see it as a proper democratic process, which is not only about voting, but discussing with those impacted, hence the block.

additionally we went down this path before, as I proposed exactly the same change when the "approval" feature was added. and the community working group tried it out, and found it made things much more difficult for them (unfortunately I can't find the notes/thread/etc where it was discussed).

on the topic itself, I totally see, and agree, that from the perspective of the new person signing up it's clunky to have to go and fill in the other form, and there are various niggles. a smoother process would be great and I'd love to see creative solutions for that! ... but we have to think about more than just the "consumer" side of things. @Akshay had a great idea to create an issue upstream, and see if a "multi field" registration form can be included in mastodon... maybe we can participate in that work.

if it is just intended to gather a quick pulse, there is no action to be taken from this vote outcome anyway? (so my block isn't technically blocking anything, but just an indication) or do I misunderstand?

I'll be honest: ideally when it comes to trying things I'd like "take a quick pulse" and "run experiment" to converge as much as possible :)

I think blocks are working like (as I understand them) they should work here: if somebody can't consent to this change if it passes, then it's perfectly fine for them to block and signal that. That raises a question (how to remove the block), and drives us all towards the right discussion. If at the end of the process blocks remain, that's fine by me; we surely will have learnt something?

But by all means I intend to flip the bit if it passes, so if it reaches the finish line without blocks (waiting of course optionally until any agreed upon conditions are met.)

See also: https://www.loomio.org/d/zoWFc7mR/relax-instance-registrations-to-approval-required-for-sign-up-from-current-nobody-can-sign-up-/32 :)

Hi all, I think it would be great to have an easier process but the one we have now serves several purposes: people have to have an account on Open Collective, they have to give a reason for joining (this helps us filter spam registrations), they are asked to tell us how they found us, and they have to agree to the Code of Conduct. If the person on call on the CWG ops team feels that there is not enough info, or something odd about the registration, they can email the person asking for more info. When a registration is approved, we send an email with additional info (about Loomio, about Meet.Coop) and our names and usernames on the instance.

The ideal process would enable a person to sign up via Mastodon, with an editable form so we could ask the questions we want to ask, and then, dream of dreams, have a shared sign-on for Mastodon, Loomio, Open Collective, and Matrix/element.

i love this dream of dreams

Thank you for the background, Matt! That helps a lot.

• I'm sorry but I still don't see why all these things must happen before people sign up for the instance. If we found a process that allowed us to automatically get back to the user with the requirement/instructions (say, via email), would that suffice to change your mind?

• What if the signup page showed the requirements inline, or at least linked to the form?

Will check the complexity of customizing the sign-in flow.

Tangent: why is the Open Collective something people must do upfront? That seems like a barrier to entry, and one that maybe puts the support aspect of the cooperative front and center (do we want that? some users with limited resources might feel nervous?). To be maximally inclusive, why not let users in "earlier" and then ask them to meet requirements, say, one month in -- once they know if they like the place? Just some ideas.

I love the idea of single sign-on and I'd love to help make that happen :)

It seems to me that if you aren't sure you want to be part of the Open Collective, then you shouldn't join here. If people weren't required to join the collective first, would they still have voting rights? If so, what would stop us from having an influx of people who don't share our values?

Michael

Adding some context on why I support this idea: it is to help us find cooperators who would make social.coop their mastodon home if they knew we existed.

While our homepage displays to humans that our instance is open for registrations, having the admin setting as it is communicates to a computers that our instance is not taking new members and that we should not be included in lists of instances people may want to join (e.g. joinmastodon.org).

As we can see from this proposal, the tech side of the change is trivial, however there are bigger implications for the Community Working Group. My view is the planning and proposals for this work should begin there.

i also strongly agree that we should be on joinmastodon.com -- cooperation should be for everyone and we should lead the way on that <3

Thank you! And I share your vision, I see this vote as the way in which we have or at least start that conversation within the Community Working Group :)

Coming from an IRL coop i am really surprised to see this number of blocks -- is there somewhere where the meaning of each of the votes is clarified in this context? because in all the consensus-driven orgs i've ever known a block is like "You block maybe once or twice per time you are involved with an organization because it represents a failure of the consensus process that is irresolvable -- your views differ from others enough that you'd be willing to leave the organization over it, rather than work on reconciling views. More discussion won't fix this." I can see how it might be different in a digital coop, but like i said just a bit taken aback.

I say this as someone who has seen blocks totally grind organizations to a halt and destroy them -- disagreements over process turn into blocks turn into nothing ever happening. no one can assume good faith anymore because they were blocked last time, so now it's on the table much more. there isn't a pathway for discussion because the odds of a block are >>1/n_people so the odds any given proposal passes are slim. as someone just getting involved with this coop i'd like to see some context for what the votes mean, how we think of them, what happens in the event of a block, etc.!

that sounds like a lot of fear based on your experience elsewhere, but not quite matching the situation we have here.

in this situation all the blocks (as best I can understand) are about starting this with a discussion with the community working group to make sure they are included in the process (as they do the registration work currently so makes sense they are included).

both me and @Will Murphy (representing 2/3 blocks) have said we support the spirit of the idea (smoother/easier registration flow), and the other block is totally up for the discussion about it.

it's exactly about creating a pathway for discussion.

I also agree it's not entirely clear what the votes mean in our context, I think we muddle through here with a "just about works" process... could be a nice inspiration for creating a little step by step social.coop guide, that expands on the stuff in https://social.coop/terms ... like "start a discussion including relevant working groups, ... " ... although personally I like the "muddle through" approach at the moment :D ... this discussion here seems a good opportunity!

It is the opposite of fear! it is trust. The idea is that any given proposal could be blocked at any time, and the expectation is that by the time something comes to a vote, it will have been discussed and concerns that might lead to a block will have been addressed. But in any reasonably sized organization, there will always be some amount of people who disagree with some idea in principle, and so since blocks have such overwhelming power they threaten the scale of consensus. The idea with blocks being rare is that they are a signal that the process needs to be fixed: if something reaches a vote and is blocked, then conversation elsewhere has broken down.

So none of this, of course, is to say that is what you or any of the other people in this thread are doing right now, I read your post here and elsewhere as sympathetic and also still being engaged in the conversation, much like what i am describing above, so I am thinking maybe the rhythm might be different in a digital setting. Where a vote might be passed and be blocked and return again to be re-voted on several times. It seems like in that case we would need some meta-organizational system for conversations to keep track of that, because I'm, maybe ideologically, a do-ocracy kind of cooperatist: let things happen and then if they aren't working you can always undo. I see inertia as being the calcifying force that has snuffed out a lot of co-ops i've known, and fluidity is resilience.

so! being new here! i am mostly trying to take temperature about what different symbols mean, and am not trying to impose my beliefs but compare them. Muddling through is lovely and a blessing. It is a blessing that needs a fallback when things get rough, including when many voices are present! Working groups are lovely, and imo fluid overlapping groups are the way to do things, but they need a common thread!

call me wiki-pilled, but I think a wiki is a good medium for negotiating norms, so if the static terms are how we negotiate our consensus process currently i would make a humble follow-on proposal to formalize the wiki as the site of semipermanent knowledge <3

edit: i was trying to heart your post but accidentally hearted mine because the buttons are at the bottom of the post rather than the top, so that was an accident and i can't tell if i undid it so i am making this edit

Thank you for your answer! I think we're on the same page: "let things happen and undo as needed" was precisely the process I had in mind here :)

I think the blocks here are perfectly fine, given that we can all change our vote. I'm assuming this means we can use the duration of this proposal, which expires in nine days (thank you @Nick Sellen for raising that!), to have a nice conversation and see if the concerns that people blocking have can be adequately addressed.

Reading the comments, these seem like the requirements for our registration process:

currentl requirements (these are all met by current reg system)

• able to confirm that new member has an account on Open Collective

• able to confirm that new member is legit via asking why they want to join (this helps us filter spam registrations)

• able to ask new member how they found us

• able to confirm that new member agrees to the Code of Conduct

• able to send an email to new member for more clarity if info is incomplete

• able to send a post-approval email

new requirements mentioned

• remove (some) friction for new members

• don't increase friction for CWG Ops Team

• get social.coop to appear on joinmastodon.org

• avoid maintenance of a separate reg system

I assume turning on 'Approval required for sign' makes an about page look similar to post.lurk.org/about

Not sure exactly how but Lurk have edited their form to add the extra info on 'Why do you want to join?' (noting it's hometown but I don't think that's relevant here). If we did similar we would cover most of the requirements? All the bits of info would be lumped together in one freetext field, but as mentioned we could work upstream over time to break it in to separate custom fields if that was necessary.

That said, if the long term dream of dreams is to have one registration system create an account for multiple platforms, then putting all of the registration eggs in the Mastodon basket may in fact not be the way to go. Then we might want to look at something like keycloak, rather than rolling our own registration/SSO system.

tagging head of related thread re: making extended form from above: https://www.loomio.org/d/zoWFc7mR/relax-instance-registrations-to-approval-required-for-sign-up-from-current-nobody-can-sign-up-/28

Thank you all for your comments! I love where the discussion is going. We'll try to come back soon with details on the simplest way to request additional information on signup, or automatically after signup.

Thank you @Neil - @[email protected] for finding an example instance with a customized setup. I was surprised to search and not find a FR for customized signup page in the Mastodon bug tracker; will keep digging, this was surely discussed somewhere? If not I'll go to the code.

Something else to consider: do we want everyone to join social.coop or do we want to help people create their own cooperative instances?

As per Spring strategy session, my vote would be the latter

Linking the previous discussion on this before: https://www.loomio.org/d/8OBKpW71/improving-registration-process. Where the Mastodon built-in registration system was trialled.

A very relevant part of which is:

Yes, we ended up reverting back to the old system. The direct application didn't have the space to collect the information we need in a less labor-intensive way - felt like it ended up adding steps.

Which would presumably still be the case.

Ah, thanks for finding that! I did a very half arsed search before, and didn't find anything 🙏

Hi, I have some insight as a new member and developer! (Thanks for the prompt @Flancian). I personally think the current form does a good thing (https://www.loomio.org/d/zoWFc7mR/relax-instance-registrations-to-approval-required-for-sign-up-from-current-nobody-can-sign-up-/26), I can see all the questions asked being very valuable. That being said, I also see the value of having signup directly on mastodon.

Before my proposal, I would like to note that I do not think a simple onboarding will be beneficial to this community. A certain level of effort is expected (monthly contributions that I will partake in soon, as well as participation in the loomio), and if a potential can't put the effort of filling out a form then it's unlikely they will participate in a meaningful way. My support of this proposal mostly comes from the outreach potential (listings on instance lists)

All considered, I believe the single question mastodon signup is insufficient for this community BUT:

It would likely be trivial to modify the mastodon codebase to introduce our own questions. It has nothing to do with the federation, so should not be hard and should not have influence on networking. I believe this strikes an excellent middle ground, basically a verbatim welcome form through the mastodon interface.

I could probably implement this, or the tech working group. Feedback on this idea encouraged.

TD;LR: Reject vote with an unmodified mastodon instance, Support of a slight modification

Hi Evan, good thoughts! Allowing custom questions on the registration form would be very welcome, but as a couple of people have suggested somewhere in the comments above, it would be better to attempt this first by working with upstream Mastodon. ( https://www.loomio.org/d/zoWFc7mR/relax-instance-registrations-to-approval-required-for-sign-up-from-current-nobody-can-sign-up-/28)

Because:

a) it would be a useful feature for Mastodon as a whole

b) we don't want to maintain a fork over time

We should first check that such a FR hasn't previously been made at https://github.com/mastodon/mastodon/. If not, we should submit one to gauge interest / likelihood of merging. Flancian says here that he could not find one - https://www.loomio.org/d/zoWFc7mR/relax-instance-registrations-to-approval-required-for-sign-up-from-current-nobody-can-sign-up-/38.

So how should this specific proposal be voted on? I don't see a "not yet" option.

Entirely up to you, but I voted 'disagree', as I don't see the benefits yet outweighing the friction for the CWG ops team. But I wouldn't really have a problem if it went through.

As we near the original closing time, I thought of extending this proposal to keep discussing -- but then looked at the numbers and decided against it. Instead I will just let this expire and the proposal fail unless someone feels strongly that we should use this particular thread to drive consensus on some potential improvement.

My reasoning is that Disagree + Block (52%) exceed Agree + Abstain (48%), which in my reading means that there's more people actively not consenting than actively consenting at this point in time.

Thank you for your opinions and information! I will try to use the positions you expressed to inform future discussion, and update relevant documentation to link to the discussion here.

@Flancian as a next step, maybe we could form an ad-hoc committee with tech & CWG reps so that we can spec out CWG requirements for the sign up process an create a proposal that meets those while also setting the instance to invite mode

I broadly agree with what seems to be the consensus here, which is to say that there is room for improvement here but flipping the switch as-is doesn't seem like a good idea.

I've made changes to Mastodon before and would be happy to help out with that process if that's something we decide we want to do. I took a quick look at the issue tracker to see if someone has requested this before, and the closest I could find was this issue: https://github.com/mastodon/mastodon/issues/10590