Note: This discussion was imported from Loomio. Click here to view the original discussion.
I think as long as the majority vote comes through, and it’s not a horribly disproportionate number (for example, a closing proposal consisting of only 2 or 3 votes is just no good, and ought to be considered a dud), then it should probably pass. People are going to miss votes sometimes, and not everyone wants to vote on every proposal.
The thing to keep in mind: does a proposal truly have a majority of the users that are on here? At the very least, are the no votes outweighed by the yes ones?
I don’t think that all members should have to vote. Should a vote be held up, just because one person went on vacation, and forgot to check their email?
There should be some sort of quorum requirement, though, such as 2/3 attendance (i.e. a proposal passes or fails once the time runs out, and 66% or more members have voted).
If we’re going to go with a minimum number of attendees voting, should we also consider a minimum length of time for proposals, to give as many people as possible the chance to vote?
I say “yes”.
Well it’s interesting. I think I revert to being a broken record: I think that we should invite more people here. I strongly feel that there is an under-representation of non-teckies here. And I’m not saying that because I think you all will vote against me whatever I may vote for or against! 
Perhaps we might decide that Loom.io (the Loom), is working? that we like it and that we want to use it to build consensus in the community? If we are decided then I think we should start making it more public for people to come and join if they want to come here. That means just plain old users on the stream.
Is that a horrible suggestion?
I would certainly feel better with more voices here, and more plurality, as well.
I also think defining a quorum is a great idea!
It’s true not everyone is going to want to vote on every issue. (but that is also what the abstain vote is for. Someone is weighing in that they will go with the current in whatever the vote ends up being up or down).
Proposal: Should we have a minimum length of time for proposals?
Outcome: N/A
Votes:
- Yes: 1
- Abstain: 1
- No: 0
- Block: 0
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
Altruism, this discussion is about quorums. The length of time for a proposal is irrelevant if only 2 people vote on it.
I’m not sure about this Brent, but I think that the length of time for a vote has to do with quorums, doesn’t it?
I’m not sure. It’s an interesting question. In a parliament the vote is voted on immediately once there is a quorum to vote. But when dealing with asynchronous discourse, perhaps we need to decide how to decide on length of time to vote since people are in different time zones and have lives?
I’m not sure I have a clear opinion on this. How might we acquire more info on it? Is there a convention?
Brent, what gave you the impression that I do not understand that?
MP: I think there needs to be both. Votes shouldn’t be rushed, and we need to have a minimum number voting.
I think we need to put together teams and direct some kind of loose infrastructure before we invite every casual user on the stream. Frankly, I think non-technical people voting on technical decisions is a bad idea. As a project largely consisting of code, I think technical people need to be the ones making technical decisions. It’s just common sense. Governance and community-facing proposals are a different story though. Part of the reason things like Shapado/ GetSatisfaction ended so badly was because it was largely requests consisting of “Add a dislike button!”, “implement my feature idea that had no realistic way of being implemented!”, and “design your features to be more like Facebook’s!”.
If we had a bunch of people that had no idea of how D even works making proposals about its future, I don’t think the outcome would be a very positive one. This is why we need to get devs and docs organized, developers are the lifeblood of any FOSS project. I think flooding our board with a bunch of people that don’t understand coding could be catastrophic.
We’re a FOSS project. Code is part of our very cornerstone. If we want to get more people over here, we must provide infrastructure.
@Brent: I think that there are actually more nuances now that I consider it.
- We need a quorum to propose to move to a vote.
- We need to decide how to determine the length of time to leave a vote open so that people have the time to live life and also participate.
- We need to decide what happens if not all people vote? How do we deliberate that? Or do we have to even deliberate that? Do we just have trust in the good faith of our members that all people will be friendly and open about this process? (I’m for that actually).
Do you think it is OK that if something is decided quickly that that decision is understaood to be more volatile than one that was left open to vote for a week? I’d think that if something were voted quickly this could be a thumb to the wind, but it would also be understood that quick decisions can be revisited if there is enough momentum in the quorum to do so.
That way no one feels like midnight votes are made. If someone doesn’t vote at all over the course of a week, then I think we can safely say they are abstaining (unless they get off their duffs and speak up!)
What do you think of that?
Sean, are you a developer?
Hi Sean!
Thanks for weighing in on this. Respectfully, what you propose is actually what was done before, wasn’t it? Teams were made, but now outlet was given to regular users. That is why they flooded the tech forums. You can’t blame them for that.
That is just bad design in the system.
What I would say is that if people know they have a place to speak their minds safely and without derision of them speaking their minds (because they are taking the time after all because they care), that a magical thing will happen. People will know that it is not a good idea if you don’t understand what is being discussed not to put your nose there. But people should be free to see what is going on.
On the other side of that, I’m not sure I agree with your assessment of it being catastrophic. You can’t say that it was a catastrophe that people were speaking up because they had nowhere else to speak up. In this sense, I think a good compromise is to have a place for them to speak, and let people decide on birds of a feather where they want to congregate. Setting up teams ahead of time is too controlling I think. I mean some people here are just doing it without waiting for teams. If someone supports that effort let them congregate with that person. This notion of teams ahead of time before deciding the direction of the community is odd.
I would say by creating spaces for unwitting users to say, “add a dislike button!” will most likely make less of those kinds of requests happen. This is because there will be transparency that there is no consensus for a dislike button. If there is consensus, then that raises the issue to the devs to discuss it.
The thing is it never gets that far down stream because the devs have a low tolerance for unwitting users asking for features. Why not just let people ask and explain to them what has to happen to make a new feature be seriously considered by the devs (say by asking them to find more people who feel the same way and building a case for it? Then bringing discourse up a notch in the deliberation process. If a person has to go through a little bit of hassle to ask for a feature, then they won’t ask unless there is clear support for it.
If it can’t be done, then it can’t be done. So what’s wrong with that? In time everyone will know it and stop asking.
“One of the penalties for refusing to participate in politics is that you end up being governed by your inferiors.” (Plato).
I wonder, what are the penalties for refusing users to participate in a FOSS project?
@MP: Quite the contrary, what happened in the past was problematic for two reasons:
1.) A very small team made all the decisions of the project, and some of those decisions did not sit well with the community.
2.) Regardless of which way you look at it, the userbase flooded us with feature requests that were any combination of the following:
A) A bad idea
B) An idea with no feasible way of being implemented in an easy or timely fashion.
C) Complaints that some clone of another network’s feature wasn’t present.
If anything, we had outlets in the past. We had a Discuss list, and we tried different services over the past two years. And you know what? All those services (save for Discuss list) more or less backfired, and because there wasn’t much of any infrastructure in the past, the problem compounded itself.
At this moment, the community devs need to come together to make decisions about the platform - what to do in the short run, what to do in the long run, and how we get from Point A to Point B. These are technical issues to be dealt with for the most part, and we need infrastructure now more than ever. One of our biggest mistakes in the past was not implementing much of any infrastructure at all, save for some loose guidelines.
My concern is that when you have a bunch of people flood the place where we make such big decisions, things could get really messy without guidelines in place. Governance without structure is hardly governance at all.
@Altruism: Yes. I am a developer. Maybe not a great one, but I can understand most code put in front of me enough that I can propose technical ideas. You’ve no doubt seen a decent share of my ideas in those couple-hundred-page threads on my D* profile.
I wouldn’t think of it as “refusing users”. I am simply pointing out that a true 1:1 direct democracy is problematic when you try and flood in tons and tons of users. We should set up some ground rules first, make sure our tools and sites are solid, and then invite more peeps, not the other way around.
@Sean: The bad will, if there was any bad will in the dev community (from what I witnessed out on the stream) had to do with a lack of communication. You know this. People were hurting not because they were flooding all these tools. They were upset and confused not because there were not enough teams. They were upset and confused because:
- there was no ONE place to air their concerns.
- If they did air them, they were dismissed or ignored.
- and everyone saw this behavior, so why bother to participate in that?
This has compounded.
IMO, a lot of this could have been cured by just having clear links to these forums and stating at the location of the link on the main JD site where to go and who to contact if there was any confusion. No one lead the stream of discourse, and so it ended up instead out on the stream!
I personally have felt left to my own devices and then been treated in not such a friendly way for making contributions that I made in good will. I even was willing to dive into IRC, which I find terribly problematic, especially for ordinary users.
I don’t want to go over further into the history for fear of causing more bad will, but I don’t think I can accept what you are saying as the reason for the breakdown in community is because people had bad ideas and didn’t understand what development means or because of mindless complaining. I don’t think that is giving people a lot of credit.
In response to all the tools used, that is exactly to what I’ve said all along. Throwing tools at the problem isn’t working. Having a clear message about what Diaspora will help alleviate a lot of the stress here.
To be fair, I recognize that the core devs have been through an unusual journey, and I know it hasn’t been easy. I am very sympathetic to it actually. There are a lot of people who want to see the vision materialize. That is if the original vision is still on the table. I think now people want to know what that vision is. We are all waiting to hear it to know if we want to participate or not. You can’t blame us for that.
So this is why I’m a broken record. Define the objective of what this community is. Allow people to respond to it and see what shakes out from it. You might actually be pleasantly surprised what comes up to the surface.
or you might not! 
such is the risks of FOSS right?