json-schema / project-info

JSON Schema specification soon back on http://json-schema.org
http://json-schema.github.com/json-schema/
6 stars 1 forks source link

[Review] Changes and guidelines #1

Closed nickl- closed 11 years ago

nickl- commented 11 years ago

@fge @garycourt @Julian @kriszyp @penduin @geraintluff @richievos

Due to recent events, which were amicably resolved, it has become evident that there are vast differences between what each individual team member expects or feels strongly for or against. This has the damaging effect that many assumptions exists as to what everyone should know and how they should behave which might not necessarily be the same as your believes. This only proves that we are different and does in no way mean that we cannot work together as a team.

For these reasons a need exists to find a way to bring everyone up to the same level and reach a common understanding of what our goals are and what is expected of everyone so that we can foster mutual respect and work as a team instead of individuals from different backgrounds working against each other. In hopes that this creates a more pleasant atmosphere and mutual respect so that we can serve the community to the best of our ability.

I need to make it clear: these are by no means being dictated to you nor should it in anyway restrict you from doing what you need. Everything is open for discussion, they are suggestions to help improve the atmosphere, and by no means is anything cast in stone. These are not my ideas and are based on the practices employed by the Apache Software Foundation.

For your review the following items are brought to your attention.

Wiki pages for your review

The following teams were established

Project Owners have admin rights to the different repos and a suggestion to separate the concerns by creating individual repos for each json-schema document proposal

Semantic team to group all members.

Please have a look and make make your assessments with specific considerations to

Please cast a vote in agreement/disagreement of the proposals.

Thank you for your consideration...

fge commented 11 years ago

Hey, this is not a 100-person project yet :p

As far as I am concerned, the situation is like this: we are people interested in making JSON Schema going forward, we have resources at our disposal, and which we are responsible for. And we, individually, don't know everything, cannot know everything. We can make mistakes. Hence the most important part to me is peer review.

Defining structures, procedures, privileges and guidelines, why not; but not to the point that they become more of a burden than a help. And given the number of active people on this GitHub organization at the moment, I personally do not think such a thorough organization design is granted at this moment.

I have yet to read everything! I'll get back with more comments.

geraintluff commented 11 years ago

This seems far too heavy-weight - the Apache stuff is pretty huge, with loads of contributors, and so this "meritocratic" whatever makes sense for that kind of project.

When you have few enough people that you can count them on your fingers, I think this kind of thing isn't a good idea. I think it only serves to put people off.

Also, conventionally one proposes these things and then implements them, if people want it.

Julian commented 11 years ago

I don't know or care to know much about recent events :), but "every merge to master requires review by a committer other than the author" seems like a good basic rule to follow in these matters.

nickl- commented 11 years ago

tl;dr summary

does bullets make it any less tl;dr ??

It's really straight forward.

Meritocracy:

Advancement in such a system is based on perceived intellectual talent measured through examination and/or demonstrated achievement in the field where it is implemented. - source wikipedia

Project roles

Roles are executive only and grants no member any authority over other members

Users:

Uses project. Anyone, no expectations; => evangelising, new user experience reporting, gratuity

Contributor:

contributes: Anyone, no expectations, no required skill, no selection process; => partakes on issues, bug and feature reports, pull requests

Committers:

a committed contributor; Anyone who shows willingness and ability to be a team player; nominated by committers, voted by PMC; remains as long as contributing. => aside from assisting contributors and casting binding votes committers continue doing what they used to, but now has commit-then-review

PMC

above-average committer respects strategic direction and long-term health; invitation from PMC vote members; => code review, strategic planning, approve governance changes, manage copyrights of outputs;

PMC Chair

Single user, voted in by PMC, coordinator and facilitator, ensures governance processes are adhered to; remains till step down 2/3 PMC vote; has casting vote only if consensus cant be reached.

Decision Making Process

Lazy consensus

In order to prevent endless discussion and continual voting majority of decisions are made when nobody explicitly opposes a proposal (has community. support)

Process involves:

Voting

Types of approval:

(bind votes only)

Voting required?

Most action /azy consensus, simply state intent and proceed unless objected.

Some actions which require voting

nickl- commented 11 years ago

@Julian "every merge to master requires review by a committer other than the author" seems like a good basic rule to follow in these matters.

I agree wholeheartedly, you would use a feature branch to commit to and then have that merged to master. There's nothing special about the feature branch it can be subjected to CI in the same fashion as master and we can ensure its working as expected before the merge.

This gh-pages however does not exactly work as that wel with git flow as only master can ever be tested and that only after the fact. Indeed we can use our personal repos to submit pull requests but this has for one the disadvantage that only one person can work on it and the merging nightmare thus instills is enough to cause sleepless nights.

Perhaps we can do something else.

It would appear that we have a catch all CNAME on json-schema.org

; <<>> DiG 9.8.3-P1 <<>> dev.json-schema.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39202
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dev.json-schema.org.       IN  A

;; ANSWER SECTION:
dev.json-schema.org.    1073    IN  CNAME   json-schema.org.
json-schema.org.    1074    IN  A   204.232.175.78

;; Query time: 13 msec
;; SERVER: 196.7.7.7#53(196.7.7.7)
;; WHEN: Mon Jan  7 19:33:17 2013
;; MSG SIZE  rcvd: 67

Which may very well mean that we can create a separate repo for dev.json-schema.org as a collaborating development snapshot which is testable (Use robots.txt to keep search bots out) and once we're happy merge it to live.

@fge @geraintluff Is this something you can agree with?

tl;dr create a repo as dev snapshot for dev.json-schema-org to use as staging platform for review before pushing live.

fge commented 11 years ago

@nickl- :

As said, we all share the feeling that a complex governance model is just not needed; when, and if ever, the need arises for establishing a set of rules, we will then act accordingly. Just not now. At least, that is my feeling about the matter, and I am sure other people implied agree with me.

As to the general CNAME, there is one exception, and that is mail.json-schema.org, which is the only MX entry for json-schema.org for that matter (its IP is within an AS belonging to a Canadian company and geoip says the IP is located in the US -- that is all I could gather as information, I haven't tried contacting the company or anything).

As for testing gh-pages changes, I don't know... If it were only "us", a separate repo could be doable, but that would complicate matters of gathering contributions, and it would require some host somewhere, whereas *.github.com is available and provided by GitHub. At a first glance, I don't think it is a good idea.

nickl- commented 11 years ago

@fge About dev.json-schema.org You are not understanding my proposal I will have to show you.

Nothing that we can't undo again so no problem.

fge commented 11 years ago

@nickl- OK, mind sending me a mail explaining the process behind it all (understand: the technical process) so that we do not fill this post with unnecessary details?

geraintluff commented 11 years ago

OK - the consensus here is that the complex governance model is not needed. As we grow bigger, we can talk about it again.

Nothing that we can't undo again so no problem.

As it's not needed, it should return to how it was - apart from the one for tests, the extra repos and teams are not useful.

I would undo it myself, but I appear to have mysteriously lost all admin rights when you re-organised everything. I'm happy to clean it up myself if you sort that out first.

fge commented 11 years ago

OK, let's be clear.

I am the "inheritor" of JSON Schema, given that Gary left that over to me (including the admin rights on the Google group). I chose to step away for a while because of my disagreement with the current addressing model of JSON Schema which made me really angry.

I still am involved: I will continue writing specs, I will continue making proposals. I will continue writing schemas. I still feel responsible for all of that.

But I need to cool down first. Then I'll rejoin.

As to the GitHub organization -- I have just noticed. What on earth happened here?

@nickl-: let's be clear, you ARE NOT JSON Schema. We all are. We DON'T NEED a voting process, we DON'T NEED a freakin committee. Give admin rights to @geraintluff please. FULL admin rights. What you are basically doing is a takeover. For one, your reorganization means that some issues which were opened, some pull requests, instead of being visible to all members, were only visible to some of them. For instance, the web site redesign: I noticed that only @geraintluff and me saw the issue, no other member did.

A community is three things: proof of concept, running code and the presence of a community. The PoC is there, running code is there, as to the community, we are ALL ON AN EQUAL FOOTING. This governance model is a HINDRANCE.

nickl- commented 11 years ago

@geraintluff As it's not needed, it should return to how it was - apart from the one for tests, the extra repos and teams are not useful.

The extra repos were removed before you made this post so I a little confused. What do you mean by "apart for one for tests"?

I would undo it myself, but I appear to have mysteriously lost all admin rights when you re-organised everything.

Was a mystery for myself too, if you recall everyone was an owner to be exact. The repos were created where each project lead could have ownership but as you said it wasn't needed or used so got removed. If your only motivation for having admin rites are to remove things done by others or banishing people then sadly that is not in the interest of the community.

nickl- commented 11 years ago

@fge I don't even know how to begin to respond to that as there are so many contradictions.

You are ordained to be JSON Schema (whatever that means) I am not but we are ALL ON THE SAME FOOTING wtf? I have never claimed to be JSON Schema. If I recall we came together and we started this together I don't understand why you are the "inheritor" now what is that supposed to mean? Is this not a community but some inheritance bestowed on one man only? Wow?

The governance, if you read it you would know, specifically states no one member has authority over another. This makes what is going on at the google group an abomination where one man decides what is deemed suitable and what is not. There was a unanimous consensus that we are small and don't need voting to decide things or any guidelines whatsoever. These were suggested to prevent what happened before:

These are not good things in any respect!

Lets look at how things progressed the last month, in this small community that doesn't require any guidelines

One thing is clear JSON Schema is certainly not a community effort, and one thing is clear from your comment. JSON Schema is Francis Galiegue and so help you if you consider a community before him.

@json-schema Is this what we want? If you are happy that we go on like this then we can close this issue today. I would think a team effort and an environment where freedom of speech is respected with clear guidelines on how to resolve differences in a peaceful fashion without the need to get upset and common courtesy is honoured and everyone is involved when important decisions are made, together as community, would be far more rewarding then this.

I am your humble servent your wish my command, do you want to see these ideals or continue in chaos. Lets hear what you say.

fge commented 11 years ago

@nickl-

3 specifications were submitted to IETF without any review or agreement from the community

I'm sorry but this is pure garbage, mate. I have asked for reviews of the specifications for months.

nickl- commented 11 years ago

I'm sorry but this is pure garbage, mate. I have asked for reviews of the specifications for months.

Asking for months is not the same as getting these few of us to say yeah fully cool whoop whoop lets go! doing a little victory dance That is, well in my mind anyway, doing it together. Did you submit the drafts or did "We" submit the drafts? Garbage it is mate, stinky crappy garbage.

The argument is that we don't need any governance because we are just a few, would it not be super cool if you didn't have to ask and ask and actually had a process that guaranteed community support and involvement? I don't know if you think everything is working the best it could, I don't? What about the apps-discuss? Do you want support there or do you prefer it this way, well at least you get all the credit, if that's what you want.

So back to the question:

@json-schema Is this what we want? If you are happy that we go on like this then we can close this issue today. I would think a team effort and an environment where freedom of speech is respected with clear guidelines on how to resolve differences in a peaceful fashion without the need to get upset and common courtesy is honoured and everyone is involved when important decisions are made, together as community, would be far more rewarding then this.

We can have that! If you want it...

nickl- commented 11 years ago

It is agreed then.