Establish by-lines for members & hierarchy (if any) #61
Comments
|
I think we are all on the same page regarding who is a core member inofficially. The problem is that we have no arguments to back that up, nothing measurable (measuring contributions is hard, although people get an impression of them). I'd propose a membership application in a similar way The Document Foundation (LibreOffice has). We used the same approach for our Open Labs Hackerspace in Tirana, Albania (JavaScript enabled is required): https://openlabs.cc/en/membership/ I'd be supportive of something lightweight, with as much horizontal hierarchy as possible, yet which gives us the flexibility to be productive and avoid bikeshedding |
|
I don't know if it makes sense to have a secondary "member" circle outside of already being a contributor to the GitHub organization. I also get that for planning things getting buy-in or at least an opinion from the most active community members is important. But I also feel that those members are the ones most likely to make their voices heard, so I wonder if this is an arbitrary distinction to pursue? |
|
I do think that it makes sense to have some basic infrastructure in place for voting. Open to public voting could be "hijacked" if someone wants to do harm. And if that happens and you want to prevent that, what argument would you use to prevent it when it was opem from the start? This is why so many communities need a Code of Conduct; I have always thought it's common sense to be nice to each other but it seems that it's not for some people. |
|
We do have a Code of Conduct, and a while ago I attempted to put something together for voting in the bylaws, but it definitely needs fleshing out: #12. Feel free to add your thoughts! I think a common misconception is that we're a consensus based group - I don't think we are. |
|
I don't know if it makes sense to have a secondary "member" circle outside
of already being a contributor to the GitHub organization.
Consider the "Open Design" email thread. I would love to be able to direct
inquires & propositions like that via a formalized community process to
core@opensourcedesign.net or site@opensourcedesign.net
Yet, it doesn't seem to make sense for all discussions to happen in public
channels, if nothing else but for signal to noise ratio.
so I wonder if this is an arbitrary distinction to pursue?
If 100+ non-active & silent people (in Github org) can veto (by vote) and shape
the organization by sheer scale over the 10 who do most of the work will that
lead to good outcomes?
I think a common misconception is that we're a consensus based group - I
don't think we are.
In some cases, we're not, which I think is fine as per the previous point. Two
clear examples that come to mind:
- Consensus: Logo had community creation & voting process
- Non Consensus: Keeping to IRC over Slack
@simonv3 how hard is to deploy / and allow multiple classes of votes with that
nifty tool you built? A popular vote could be nice *wieght* to add vs. a
core group opinion.
|
|
@simonv3 the Code of Conduct was just am example I used, I am aware we have one. I am curious to see more input from others here so we can start shaping this |
|
My concept of consensus is one where everyone agrees to the same thing - in that light we didn't reach consensus for the logo, we had a vote and the majority won. Everyone was in consensus about sticking to the result of the vote. No one had veto power. I was always under the impression that we encouraged people to do the thing they wanted to take action on, they didn't need full group permission to do something (which is why it's nice we have version control). @bnvk I'm not sure what you mean with multiple classes of votes. quick-survey handles most basic survey questions I think (minus whatever people have raised in the issues) and I imagine most voting would fall under that. What are some things people think a requirement for being defined as a core member means? |
|
fwiw, I am with @simonv3 on this one. I rather be as light as possible when
it comes to processes and policies, unless we have strong evidence or
experience showing they are needed.
Realistically, right now I can't see anybody hijacking the community or
trying to do harm. It is also quite evident who has time and energy to
actively contribute right now and who hasn't. We also know such things are
fluid and change continuously: attrition is part of FOSS.
I'd like to be in a group where, if someone feels left out because they
were not invited to the Doodle poll or to some other thing, they should
feel free to speak up and ask to be invited, rather than classifying
members as core, non-core or some other thing.
Just my 2c. Now, back to work :)
…On Thu, Mar 2, 2017 at 11:15 PM, Simon ***@***.***> wrote:
My concept of consensus is one where *everyone* agrees to the same thing
- in that light we didn't reach consensus for the logo, we had a vote and
the majority won. Everyone was in consensus about sticking to the result of
the vote. No one had veto power. I was always under the impression that we
encouraged people to do the thing they wanted to take action on, they
didn't need full group permission to do something (which is why it's nice
we have version control).
@bnvk <https://github.com/bnvk> I'm not sure what you mean with multiple
classes of votes. quick-survey <https://github.com/simonv3/quick-survey/>
handles most basic survey questions I think (minus whatever people have
raised in the issues) and I imagine most voting would fall under that.
What are some things people think a requirement for being defined as a
core member means?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#61 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AApwUT7gcQk7g_U7D_Iw1cukoAuIlU-Lks5rh02ggaJpZM4MRASr>
.
|
|
I am fine with that approach until we really need it as well. Just keep in mind that we should be aware not to create an inofficial "clique" of those people who contribute more time in here. We could miss out on having some greatly talented contributors in the future who might not feel welcome I had this experience in Wikipedia where I did a bunch of event planning and design and was ignored because I had not many article contributions on Wikipedia. Let's just keep in mind to not put down people just because they had not that many contributions as others (yet). Not saying that we are doing it, but it doesn't hurt to check once in a while how we are percepted on the outside. |
|
Structurelessness is certainly tricky. Maybe that is something we can put in our by-laws? Something like:
|
|
That's not measurable and is subjective and due to that differs from person to person. |
|
Suggestions welcome! |
|
@bnvk How does Debian handle decision-making? I'm not really familiar with it |
|
These are all great opinions and sentiments to keep track of. It's important to
consider why I started this thread:
1. @elioqoshi voiced concern the Doodle poll was *not* open to the entire public
2. This week @simonv3 @jancborchardt and I were in an email thread with a
non-community member that I wish *had* been more open and others were aware
of even though nothing more will happen on that
3. There seems to be some mild concern over "cliqueness" forming
I fear if we do not establish at least *some* form of community agreed upon
structure / acknowledgements of how we want to (and currently) operate- in the
future cases like 1. and 2. will precipitate feelings of 3. to increase.
I also see a few separate themes in this thread:
A. Clearly defined transparent communication channels
B. Processes for group decision making
C. Newcomers traversing (or climbing) comfortably in the group
I argue that A. is the most important to get "right" as it lays a good
foundation for B. to happen on whatever issues come up, as well as hopefully
empower C. to be welcoming as possible.
The only clarity I have is my suggestion of #63 whereby we have an email
address for "core@opensourcedesign.net" which will address 2. and by design,
lay a framework for addressing what 1. is about, I think...
And if there is anyone concerned about 3. or is having bad vibes re: C. I
would hope to hear from them so we can improve :)
(@simonv3 I'll read those posts later, thanks)
|
|
I come from a community that uses the Apache voting system. We have a clear set of core contributors and only our votes are binding and we stop the process if there is a veto. The main problem is that we don't have that many contributors and we are not very welcoming to new members. Also I don't think in OSD we have vital functionality, that if we make the wrong decision once, it will affect us on the long term. I don't think we need this kind of strict voting system for the type of activities we do. Although I understand having core contributors give some of us (me included) a feeling of being appreciated and recognized, I don't think is vital for us now to adopt such a way of making decisions. I like very much the 'bylaws' initially proposed by Simon and since our community is so generic, multiple people should be able to vote, propose and benefit from it. The 51% majority for 2 weeks period seems reasonable. We are a meritocratic community and we will try to recognize and recompense active contributors, but I don't think the voting should be delayed or postponed if some 'core members' are missing. As Simon said, some people already make their opinions heard more by being active and I'm sure they will make sure their preferences will be taken into account when doing decisions. The problem, as Belen said, is that the availability and interest of some people might vary over time (depends on the projects/job status), so I believe in a community like ours the 'core' membership might shift from time to time. |
|
Took a stab at outline some of the ideas here in the FAQ page |
|
looks good to me. |
|
@bnvk yep, looks great! :) I'd only say we should avoid using the acronym "OSD", especially in headings, as acronyms are often confusing. |
While planning OSD Summit in #57 I used the wording core members in describing that I invited specific people to a planning calendar. @elioqoshi raised concern
Currently, no one decides such things. For this specific case i'm weighting my instinct based on my memory of faces & names that come up repeatedly and are actively involved in doing things like:
My personal mental list of this is about 10 - 20 people and I put myself in that category. My reasoning these people are "core" is that they / we making the collective & purpose of OSD happen and grow, consistently, over time.
In the case of organizing the Summit, I think being sensitive to these core persons schedules is more important than the 120+ other people subscribed to this repo who do not participate regularly, the other 200+ ppl in the github organization, or the 1000+ people who follow us on Twitter. However, an argument could be made for the inverse.
I am sure other cases where certain persons / groups needs will have more priority, thus we should establish a way to handling these cases.
The text was updated successfully, but these errors were encountered: