Init CONTRIBUTING

[csarven]

Adapted from https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md .

[melvincarvalho]

-1 nice food for thought, but far too bureaucratic, and puts current work at risk.

[jacoscaz]

@melvincarvalho with my chair hat on, discussing the pros and cons of this PR would be easier if you were to point to some of the parts that you find objectionable.

[jacoscaz]

Speaking from my personal point of view, without my chair hat on:

• A CONTRIBUTING.md document is badly needed to establish process. Whether this specific version of it goes through or not, thank you @csarven for your effort on this. I am not 100% sure as to which process is best suited for this group, given its history, but at some point we do need to have one.
• My primary objection is the dependency on a CoC. Generally speaking, I dislike code of conducts. I much prefer projects in which the lead or chair is simply trusted by participants (and given the tools) to keep things in check. Of course, participants should always be able to vote them out the moment they proved unable or unwilling to run the project / group to the latter's satisfaction. My dislike primarily comes from past experiences where CoCs, along with the interpretation and application thereof, became hugely contentious issues on their own. The human element, which a CoC should ideally lessen if not take out entirely, never seems to go away.
• I like the rest of the document as long as we can collectively agree to consider it a list of guidelines rather than a barrier to participation and conversation. All reference to such a document should exist within constructive feedback, as opposed to things like -1 because it doesn't adhere to CONTRIBUTING.md.

In relation to my dislike for CoCs, I want to make it very clear that, should the group decide to adopt a CoC, as the chair I would have no issues with that. The feedback above is given simply as an active participant.

[csarven]

This is the repository of the W3C WebID CG under the W3C GitHub organisation. It is W3C environment, and participation requires abiding to the terms and the spirit of the W3C CEPC (as mentioned in references in https://github.com/w3c/WebID/pull/30#issuecomment-1878409728 ). This is not negotiable.

The Contributing document is indeed a guideline for setting expectations and maintaining consistency, helping new contributors get familiar with the material, among other things. There are always some details that are not captured in a Contributing guide, and that can be introduced over time. Its mere existence is to help the group be more constructive.

[woutermont]

I must say I'm quite surprised by the reaction to this PR.

• A contribution guide is one of the most basic things in any repo, code or otherwise.

• The W3C Code of Conduct is not optional. By nature of being a W3C Community Group, we MUST comply with that, whether we want to or not.

That some people like to misuse CoCs by nit-picking over their interpretation is foremost a problem with those people, rather than with the concept of a CoC. Moreover, in the absence of a CoC committee, the interpretation of the chair(s) it just makes sense to follow the interpretation of the chair, unless disputed by W3C staff.

[jacoscaz]

/chair hat off

@csarven @woutermont

This is the repository of the W3C WebID CG under the W3C GitHub organisation. It is W3C environment, and participation requires abiding to the terms and the spirit of the W3C CEPC (as mentioned in references in https://github.com/w3c/WebID/pull/30#issuecomment-1878409728 ). This is not negotiable.

The W3C Code of Conduct is not optional. By nature of being a W3C Community Group, we MUST comply with that, whether we want to or not.

Thanks for pointing that out. I'm still learning :). In which case, I still do not like CoCs but my primary objection to this PR is a technically invalid objection and I stand corrected.

[woutermont]

No worries. In general, it is fair to assume that when @csarven says something about W3C processes, he knows what he is talking about 😉

[VirginiaBalseiro]

CoCs are needed in any organization where people are involved. They help towards safety of the people involved, as it is hard to enforce certain behaviors unless they are written down, just like with anything. It'd be in the interest of those who "dislike" CoCs to speak to some underrepresented minorities and find out whether they find CoCs helpful or not. I'd personally would not participate in any community, project or event without a CoC, and many people are on the same boat, particularly those in minority groups and allies. CoCs are not a magical way to sort out all community problems, but it is certainly a necessary foundation.

[jacoscaz]

/chair hat off... or on? not sure

Just to re-iterate as I'm aware this is a topic that hits close to home for many. As noted by @woutermont and @csarven , whether this group adheres to a CoC or not is not a point of discussion. I was not informed enough in this regard and made the (silly, in retrospect) mistake of assuming otherwise.

I hope I've made it very clear by now that my own opinions are not the group's and I'm here to serve the group, insofar as the group is happy with me. We are governed by https://www.w3.org/Consortium/cepc/ and I'm happy to do my best in adhering to it.

@VirginiaBalseiro thank you for sharing your perspective, I appreciate it. Though I do not belong to any minority, I do regularly speak with people from some of them and I do strive to be an ally, though that happens almost exclusively outside of my digital life (at least insofar as I am aware of). I surely have a lot to learn, both in and out of the digital realm, and I'm always open to changing my mind.

[melvincarvalho]

@melvincarvalho with my chair hat on, discussing the pros and cons of this PR would be easier if you were to point to some of the parts that you find objectionable.

There's 300 lines of bureaucracy which need to be read through very carefully, to ensure every member of the CG agrees. Be also aware that this group is 12 years old, one of the first CGs and predates much of the newer bureaucracy. In general, my -1s are to not merge something prematurely, which is a common issue in the W3C. We are thinly spread, and every PR needs scrutiny, which takes considerable time and effort.

[woutermont]

@melvincarvalho, I agree that we should not just adopt anything without looking at it, but this is basically a copy from the guide that has been used for years by the Solid CG. It has already seen its fair share of scrutiny and it is a fairly readable document, so unless there seem to be big mistakes in the adaptation to the WebID CG, I suggest we use our thinly spread time to focus on spec-related matters.

[melvincarvalho]

I agree that we should not just adopt anything without looking at it

Indeed. Definitely a hard NACK

We should first focus on making a spec, before blindly merging lengthy bureaucracy

We have operated for 12 years. If one of the 20+ items becomes an urgent blocker. Let's take it to the list, someone can say why they are not able to work, and the group can decide to merge a section.

I dont want to distract from the spec work, or it will not be completed. Additionally any line item could be used a mechanism to torpedo the spec, and that is right now in the balance.

So a big no here. Dont impose ways of working on people without consent. That is not negotiable.

W3C CGs procedures are documented on the w3c website. It need not be repeated here, right now, all of a sudden.

Let's focus on our spec work, and once that is successful we can look at bureaucratic items.

If the chair is blocked in some way, for example in listing a work item, he can take a single section. Prioritize it and make an urgent work item to the group which we can look at. It should be on the mailing list as it affects everyone.

For example, selecting a new Editor or a co-chair:

An example common workflow for a group our size is: 2+ ACKs no NACKs

The group has made good progress and has momentum. The best way to kill that is by bloating the workflow with bureaucracy. Any changes should be introduced very gradually, and MUST have full consent of the entire group.

@jacoscaz I would be HIGHLY cautious about merging even benign looking bureaucracy, as it could be used to undermine your, the group, and our current consensus. You have already been undermined on more than one occasion. Take sections that YOU think you need to unblock how you want to work, and then merge it section by section, if you think the effort will be worth the gain. You cant merge things blindly without consent of the whole group.

Let's focus on finishing the spec. And not get drawn into lengthy process debates which almost always kill momentum and progress.

-1000 for now, modulo urgent items selected by the chair, that go to the group, and gain consensus.

[melvincarvalho]

@melvincarvalho with my chair hat on, discussing the pros and cons of this PR would be easier if you were to point to some of the parts that you find objectionable.

Agree on this. But it's a lot of work to ask every member of the group to do. You may think it's not a lot of work, but I dont accept that. It must be scrutinized, else everything we've done over 12 years can be put at risk from a single line.

So not now. We've operated for 12 years, we can wait a little longer before taking on such a big task.

[woutermont]

I agree that we should not just adopt anything without looking at it

Indeed. Definitely a hard NACK

@melvincarvalho, I urge you not to misrepresent my words by quoting them selectively! 🤨 My point is exactly the opposite of yours: we have been working according to that guide for years in Solid CG, where it grew through iterative consensus, so we should have no problem using it here.

In the time it took you to write all your comments on this PR, you could easily have read through the proposal (it's a 5-10m read, I timed it). And since you have been contributing to the Solid CG for years as well, nothing in there should come as a surprise to you, or feel like a change of how we have been doing things up till now.

It is also quite ironic that you block this PR without even taking the time to point out any real issue with it, while at the same time your mail about using the wiki clearly indicates that you are actively spending time thinking about how our working process can be better. I can only encourage that you do that, but it is fairly hypocritical to not work together with other people working on the same.

So let's stop this stalling, alright? If you have a problem with the concrete proposal in the PR, say so and we can work on it. If not, let us merge the PR. Nothing is set in stone, if you bump into a problem with it later, you can still propose a change to the document.

[jacoscaz]

/chair hat on

You cant merge things blindly without consent of the whole group.

@melvincarvalho and all: for the time being, and ironically until this PR gets merged, we're governed by lazy consensus. Melvin, you have yourself reinforced this notion many times. Quoting from https://www.w3.org/2023/Process-20231103/#Consensus (emphasis mine):

Note: Chairs have substantial flexibility in how they obtain and assess consensus among their groups. Unless otherwise constrained by charter, they may use modes including but not limited to explicit calls for consensus, polls of participants, “lazy consensus” in which lack of objection after sufficient notice is taken as assent; or they may also delegate and empower a document editor to assess consensus on their behalf, whether in general or for specific pre-determined circumstances (e.g. in non-controversial situations, for specific types of issues, etc.). If questions or disagreements arise, the final determination of consensus remains with the chair.

/chair hat off

Now, personally I would rather continue with lazy consensus. I share your skepticism, and this PR feels to me as if process is being given too high a priority over actually working on WebID. This is what informed my third consideration on this PR, which I quote:

I like the rest of the document as long as we can collectively agree to consider it a list of guidelines rather than a barrier to participation and conversation. All reference to such a document should exist within constructive feedback, as opposed to things like -1 because it doesn't adhere to CONTRIBUTING.md.

/chair hat on

But! I'm also chair and pushing back against a request for more formal process as chair feels a bit like abusing the role of chair itself. If the group does not want this PR, the group can and should simply say so.

/chair hat off

We have operated for 12 years. If one of the 20+ items becomes an urgent blocker. Let's take it to the list, someone can say why they are not able to work, and the group can decide to merge a section.

IMHO, the fact that the group has operated for 12 years and still has not managed to produce a final version of the spec is not an argument against this PR. On the contrary, it might be an argument in favor of this PR.

I dont want to distract from the spec work, or it will not be completed. Additionally any line item could be used a mechanism to torpedo the spec, and that is right now in the balance.

For what it's worth, I fully empathize with this feeling. It's already super hard to move things forward, I'm not entirely convinced that this will help.

[woutermont]

IMHO, the fact that the group has operated for 12 years and still has not managed to produce a final version of the spec is not an argument against this PR. On the contrary, it might be an argument in favor of this PR.

I dont want to distract from the spec work, or it will not be completed. Additionally any line item could be used a mechanism to torpedo the spec, and that is right now in the balance.

For what it's worth, I fully empathize with this feeling. It's already super hard to move things forward, I'm not entirely convinced that this will help.

The point of a contributing guide is not to help us move forward faster. It is to explain those who are new to the group how we are moving forward (and to align those who are already part of the group on that process, should that be necessary). That is, it provides a everyone with a point of reference about how we work together.

[melvincarvalho]

Thank you for raising your concerns. The importance of a comprehensive review for such significant changes, similar to the attention we give to the WebID spec. It's crucial that we don't expedite this in its entirety without the group's consent. Member consent and a gradual approach are essential, especially after a 12-years of working in a certain way.

I also recognize the risks of over-focusing on procedural details, which can detract from our technical objectives. To ensure everyone's viewpoints are considered, I propose that if the chair deems this a priority, it should be brought to the entire group through our mailing list, but only the sections that are needed, for a thorough discussion period. What is here is too big. This mirrors the careful deliberation we're applying to the WebID definitions. Let's prioritize finalizing those definitions, as they require less extensive review compared to the proposed changes.

Process changes require more scrutiny than technical specifications because technical changes affect only implementers, and process affects everyone. You must gain consent. @jacoscaz if, and only if, you feel blocked, please go to the group and prioritize a few sections of this, and not merge until objections are removed. Dont merge controversial items quickly. Though you can have a tie-breaker if the group is blocked in some way.

It's taken us 6 months to make good progress and momentum on WebID definitions which is less than 50 lines. This is longer than that, so formal objection to merging in Q1 or Q2 until everything is fully agreed, and im emphasising that will take as much time as the group needs to understand every line.

[jacoscaz]

/chair hat on

Coming back to the matters of process after working on #37 to establish whether we can roughly agree on a way forward, and I think the answer to that is a positive one, I'd like to clarify that I do agree on the general point that we do need a more formal process going forward, if only for self-preservation: lazy consensus is downright exhausting.

While I might personally think that the process brought by this specific PR is too much, this is the only PR that attempts at introducing more formal process and it is supported by people much more experienced than I am in matters of process (and many others, to be honest). I'm going read through all of the referenced material in the next few days but if a majority of the group thinks this PR to be a good way forward, then I think we should merge.

[melvincarvalho]

lazy consensus is downright exhausting.

Fair!

While I might personally think that the process brought by this specific PR is too much, this is the only PR that attempts at introducing more formal process

-1 it is too much, too many sections, the small print needs scrutiny, and that is a bigger task than the spec.

It affects the whole group, there is no consent. We have been working together for 12 years, or up to 17 years if you include what came before. You must get buy in, you cannot impose it.

I'm going read through all of the referenced material in the next few days but if a majority of the group thinks this PR to be a good way forward, then I think we should merge.

-1000 days is not enough, so I will block this merge in January with a formal objection, on behalf of the group.

Also the group must set aside time to, and some may be away, or not prioritizing WebID at this time.

it is supported by people much more experienced than I am in matters of process

And opposed by.

This needs scrutiny and time, and will take months not days.

Be also aware that in other groups it is a slippery slope. Once process is introduced it not only a green light to iterate on it indefinitely (there are 100s of commits to process in other groups, more than specs) but also distracts from the spec effort, and also IMHO it is more the case that bureaucracy blocks progress than enables it, and also can torpedo the whole thing.

Let's compromise!

Of the 20+ sections that you would like to merge pick the ONE that is most important to you, in terms of being able to work. And we can commit review it this month.

For example we can move forward now without lazy consensus, for the agreed upon spec items, ie subset/supset work, where the chair can act as a tie-breaker or, as a last resort, call a vote. These things are complex, and every group has its own dynamic. Lazy consensus was proposed as we were blocked, but we are no longer blocked.

if only for self-preservation

I am mindful of this, and if you ask it, I will direct some attention to something you consider to be urgent.

As such I'll review 1-2 sections, and leave comments inline.

[melvincarvalho]

I've done quite a bit of review on this. I formally object to it being merged in Jan 2024, but will look again at it, at the end of the month, so that it doesnt become overly focused on.

I strongly would like to facilitate the chair's quality of life, and will compromise, for that reason. If @jacoscaz can articulate what he wants, and how we can help, I will spend some cycles to help.

To my mind work items should be in 2 categories

• historical
• current

We should not take on too much, or everything is at risk, and things should be done in a logical order. A refactor should precede a historical update, or there will be chaos.

Regarding consensus, there's not much in there. The implied w3c stuff that allows for formal objections should be fine. The powers given to the chair to make a tie breaker on a work item, or call a vote etc. should be fine. I trust the chair's judgement. Bear in mind that consensus is hard. There is no magic formula. All good open development works on a web of trust, which cannot be codified.

In general, the thing I dont like about this, is that it seems to be a green light to flood the historical specs with new updates of different classes, and will muddy the waters and potentially detract from the work we are already doing. It's taken us 17 years to get this far, and we are close to a major milestone. Let's slow down and get the refactoring over the line. Then once everyone is unblocked it will be much easier to figure out next steps including process and technical work items.

[TallTed]

[@melvincarvalho] -1

I think much more comment is needed if you want to convince others of your position.

nice food for thought,

That seems a positive review...

but far too bureaucratic,

This is not very different from other W3C CG or WG contribution processes, so I wonder what parts in particular are "too bureaucratic"?

and puts current work at risk.

Exactly what work would be put at risk by formally adopting this CONTRIBUTING.md?

[TallTed]

We have operated for 12 years

More accurately, this CG has not operated for that time, as it has been largely dormant for most of those 12 years. "Operation" implies "getting things done" which ought to include evolving the primary document from an Editors Draft to CG Report (the final product of a CG) and thence through a WG to a W3C CR (then W3C PR, then W3C TR). CONTRIBUTING.md and other recent activity should hopefully help us be more operative and productive for the next year or three.

[TallTed]

lazy consensus is downright exhausting

Yes. It's also VERY hard to document without a fairly onerous level of record keeping, tracking when any given question was raised, what options were offered, and when the "lazy consensus" was adopted as a decision.

Even "lazy" consensus generally benfits from some clear "barring objection by DATE, the question of WHAT TO DO ABOUT BRUNO is answered by WE DON'T TALK ABOUT BRUNO." (smily captioned, just in case someone doesn't recognize the moderately obscure Encanto reference)

Such calls for objection SHOULD be made in a broad manner, such that even a casual participant of the CG is LIKELY to see them — so posts to the mailing list can be helpful, but GitHub Issues and/or PRs can be more visible, depending on the participant's work patterns. Sometimes two weeks or so is sufficient window, but often enough a month is better, or even longer — especially if there are no regular conference calls or similar.

[TallTed]

I will block this merge in January with a formal objection

Note that formal objections cannot be made before a decision is made. Formal objections only apply to decisions.

on behalf of the group

Please do not try to speak on behalf of the group until and unless we (the group as a whole) elect you to do so.

[jacoscaz]

/chair hat off

barring objection by DATE, the question of WHAT TO DO ABOUT BRUNO is answered by WE DON'T TALK ABOUT BRUNO

@TallTed I caught that and it made both me and my wife smile :)

To your point, though, I agree! Even should we decide to continue with "simple" lazy consensus, which I don't think we should, that's nonetheless something that ought to be clearly stated in either the README.md or the CONTRIBUTING.md file, along with how much in the future DATE should be from the call for objections.

It's very hard for newcomers to figure out how the group operates at this point in time.

[melvincarvalho]

Exactly what work would be put at risk by formally adopting this CONTRIBUTING.md?

All work. I feel this is getting rail roaded through.

300 lines here distract from webid specs which may be fewer lines.

You are imposing conditions on a group that's worked together for 12 years, in some cases longer.

It's being prioritized on an accelerated timeline and the timeline of our primary work has suffered.

Asking for a pause to even read the doc carefully is not granted.

@jacoscaz please dont rail road through a large bureaucracy. And impose it on the group without their consent.

Why cant we have the same time to read it, as we do to read the webid spec.

It's not OK for a small group of people to say, "I want to work like this, now everyone has to work like this".

Bureaucracy always starts out serving the group, and ends up serving itself. The burden of proof is not to say why 300+ lines of dictums are bad. The burden of proof is to take one piece and say why we need it, and get universal buy in.

[melvincarvalho]

The very first section of the bureaucracy institutionalizes this repo as the exclusive place where webid spec work is done. Yet not everyone has equal access to create branches. That's not OK, any proposal needs to be inclusive or optional.

[melvincarvalho]

Additionally, I've noticed that this particular issue is being created in the GitHub / webid namespace, which not only gives them a more formal appearance but also seems to implicitly prioritize them. Considering that not all group members have the capability to do this, it raises concerns about fairness and equal treatment in terms of work prioritization. I believe it's important for us to ensure equitable access and avoid favoring certain users over others in these processes.

@jacoscaz could I ask you to hold off merging for the month of January. Not everyone here has a full time job working in this space, and time needs to be found to allocated to agreeing to terms which may contain small print. If there is not timeline given for merge, everyone is on edge and it could get rail roaded through, and members have to drop everything in order to do that, and that in turn eats time from the main work.

There must be a way to pull the emergency brake.

[melvincarvalho]

Another thing that's HIGHLY problematic is that, for example, @TallTed is able to review this and other PRs, yet others are not, by virtue of it being in the w3c namespace.

That is also not OK.

Pull request authors can't request reviews unless they are either a repository owner or collaborator with write access to the repository

Immediately rectify this by moving the PR to another namespace.

Either give everyone the same permissions or let's work somewhere were the whole community is treated equally. I'm insisting on this one.

[TallTed]

The very first section of the bureaucracy institutionalizes this repo as the exclusive place where webid spec work is done. Yet not everyone has equal access to create branches. That's not OK, any proposal needs to be inclusive or optional.

Branch creation within this and similar W3C-related repos is typically limited to document Editors and/or Chairs. You (and I, and anyone else) can always fork this repo (whether to your own machine or within the GitHub.com environment), create new branches there, and submit PRs thereby, which may result in new branches for further work or in simply being merged into the main branch.

WebID began as, and to my knowledge remains, a project of W3C-based groups. IG/XG and WG were a decade or so ago, and there's been a CG since around the time the WG's charter expired. The current plan (as I understand it) is to let the W3C Solid WG adopt the draft WebID spec and shepherd it through to W3C REC, which was its originally intended destination. This is (part of) the way W3C-based groups work. You don't have to like that, but as things stand, you do have to accept it and work within it, as long as this remains a W3C-based effort (which I think is right and proper, not to mention supported by existing IP agreements).

Additionally, I've noticed that this particular issue is being created in the GitHub / webid namespace, which not only gives them a more formal appearance but also seems to implicitly prioritize them. Considering that not all group members have the capability to do this, it raises concerns about fairness and equal treatment in terms of work prioritization. I believe it's important for us to ensure equitable access and avoid favoring certain users over others in these processes.

The draft WebID spec was migrated to this GitHub repo from a different version control system where it had been languishing for most of the past decade. ANYONE can create an issue in this repo.

I don't know what you mean by "a more formal appearance" nor "implicitly prioritize them". To my eye, a GitHub issue is a GitHub issue. None intrinsically nor automatically appear more formal than others. Neither is there any inherent prioritization to these. The WebID CG and any WebID-adopting WG (the group as a whole; not the chair nor any editor on their own) is empowered to set priorities, usually achieved through a combination of labels and milestones, often addressed through (semi-)regular conference calls, F2Fs, etc., toward delivery of what is hoped to become a W3C REC.

Another thing that's HIGHLY problematic is that, for example, @TallTed is able to review this and other PRs, yet others are not, by virtue of it being in the w3c namespace.

Anyone is able to review these PRs. Challenges around intellectual property, including the W3C Patent Policy (for WGs) and the W3C Community Contributor License Agreement for CGs, mean that substantive contributions including those made via PR review can ONLY be accepted from official group members who have agreed to those IP protections.

Pull request authors can't request reviews unless they are either a repository owner or collaborator with write access to the repository

That's not quite accurate, even if it was taken from GitHub documenation.

GitHub's tooling automatically requests PR reviews by those listed in CODEOWNERS, who are typically chairs and/or editors of the document(s) in a W3C-related repo. GitHub also offers a simple menu through which reviews can be requested from collaborators (i.e., contributors of past merges, found in the git blame data) in the repo -- who do not necessarily have write access, themselves. ANYONE can look at a PR (e.g., this one, #31), and click to the Files changed tab, and submit a review with change requests, comments, etc. ANY GitHub user can be tagged on an issue or PR (by including their @handle in a comment) and asked for their input.

Immediately rectify this by moving the PR to another namespace.

Either give everyone the same permissions or let's work somewhere were the whole community is treated equally. I'm insisting on this one.

I cannot speak for others here, but I know I don't respond well to ultimatums. I respond even less well to ultimatums that are based on incorrect assumptions (e.g., that the "whole community" isn't being "treated equally").

Please adjust your tone, investigate your assumptions, and try to adopt — or at least present — a more collaborative and less combative attitude.

[webr3]

### New work item proposal

* Propose new work item as an issue in https://github.com/w3c/WebID
  and propose it as an agenda topic in a group meeting.
* Include publicly accessible link to abstract or draft.
* List and link to owners (at least 1 person for advancing the work item and 1
  other person).
* Answer the following questions in order to document how you are meeting the
  requirements for a new work item at the W3C WebID Community Group. Please
  note if this work item supports certain programs or another government or
  private sector project.
  1. Explain what you are trying to do, using no jargon or acronyms.
  2. How is it done today, and what are the limits of the current practice?
  3. What is new in your approach, and why do you think it will be successful?
  4. How are you involving participants from multiple skill sets and global
     locations in this work item? (Skill sets: technical, design, product,
     marketing, anthropological, and UX. Global locations: Africa, the
     Americas, APAC, Europe, Middle East, Antarctica.)
  5. What actions are you taking to make this work item accessible to a
     non-technical audience?

There are no group meetings, there is no agenda for them. This CG is to create abstracts and drafts, adding a process which defines abstracts and drafts should be done outside of the CG disables the CG. Existing listed Work Items do not reflect the current status of the group or what it's working on. If adopted this would immediately disable the CG from doing what it's doing.

-1 Remove it all.

## Publication Rules

W3C CG reports are not required to follow the publication requirements as W3C
reports [on the standards track](https://www.w3.org/TR/). However, we
recommend using the [W3C's Publication rules for Recommendation
(“REC”)](https://www.w3.org/pubrules/doc/rules/?profile=REC) as a guideline.
WebID CG's technical reports differ along the lines of document status,
rights, identifiers. To help readers already familiar with W3C technical
reports, it is recommended to maintain the same look and feel.

See also the [W3C Manual of Style](https://www.w3.org/2001/06/manual/)
guide containing best current practice, written for editors and authors of W3C
technical reports.

We also make the following recommendations:

* MUST be a valid HTML5 document (see also the [W3C Markup Validation
  Service](https://validator.w3.org/)).
* MUST include published and modified dates (`YYYY-MM-DD`).
* Follow the [Internationalization Best Practices for Spec
  Developers](https://www.w3.org/TR/international-specs/).
* Follow the [Linked Data](https://www.w3.org/DesignIssues/LinkedData) design
  principles. Give all significant units of information, e.g., concepts,
  requirements, an identifier, and provide a description using a concrete RDF
  syntax (see also [Spec Terms](http://www.w3.org/ns/spec)).
* Cite the source resource in which consensus was reached for a given
  statement.
* Changelog from previous published releases (if applicable).
* Considerations section, e.g., [Self-Review Questionnaire: Security and
  Privacy](https://www.w3.org/TR/security-privacy-questionnaire/),
  Accessibility, Internationalization, Societal Impact.
* Conformance Classes section to identify who and/or what will implement the
  specification.
* Document wilful violations.
* Use consistent spelling throughout the document.

None of this was ever agreed by the CG participants, it inhibits the group, editors, chairs for working on abstracts and drafts.

-1 Remove it all.

### Processing pull requests

Unless there is a prior CG decision otherwise, changes to TRs use the W3C Process [Correction Classes](https://www.w3.org/Consortium/Process/#correction-classes) as follows:

|Correction Class|Requirements|Time|
|-|-|-|
|[No changes to text content](https://www.w3.org/Consortium/Process/#class-1)|Editors MAY PR and/or merge at their discretion.|Within 5 days or 2 meetings.|
|[Changes that do not functionally affect interpretation of the document](https://www.w3.org/Consortium/Process/#class-2)|Editors SHOULD PR and/or merge at their discretion.|Within 5 days or 2 meetings.|
|[Other changes that do not add new features](https://www.w3.org/Consortium/Process/#class-3)|MUST PR.|Within 10 days or 2 meetings.|
|[New features](https://www.w3.org/Consortium/Process/#class-4)|MUST PR.|Within 10 days or 2 meetings.|
|[Changes to the contents of a registry table](https://www.w3.org/Consortium/Process/#class-5)|Editors or chairs MUST PR.|Within 10 days or 2 meetings.|

-100, there are no TRs Remove it all.

[melvincarvalho]

Branch creation within this and similar W3C-related repos is typically limited to document Editors and/or Chairs. You (and I, and anyone else) can always fork this repo (whether to your own machine or within the GitHub.com environment), create new branches there

@TallTed CGs operate on a principles of fairness, which is non-negotiable.

Any member must accept the principle of fairness, or ultimately be required to resign from the group.

It's not fair merge branches directly into this repo, because some have the privileges and some do not, and it gives disproportionate attention.

Please redo this PR in a way that's not a direct merge. Please delete this unauthorized branch. Redo it to incorporate the feedback, from a forked branch. It is not acceptable to merge as is.

I suggest shortening it, fork this repo, and add just the things that you feel you need to work, and that are most likely to gain consensus.

[jacoscaz]

/chair hat on

All right, let's calm down. No matter where we all stand, let's maintain a positive and constructive dialogue. I echo @TallTed 's invitation, which I extend to everyone:

Please adjust your tone, investigate your assumptions, and try to adopt — or at least present — a more collaborative and less combative attitude.

No harm is done until a PR is actually merged in the master branch against the group's will. Nothing of the sort has happened so far, there's no reason to get overly confrontational. For now we're governed by lazy consensus, with yours truly being ultimately in charge of working through irreconcilable differences. As part of finding a shared ground on process, we will also come to an agreement on whether branches and PRs may be opened from within this repository by those who can - by virtue of their status within W3C or the repo itself - or whether we'd rather do things differently.

We need more formal process precisely to regulate things like these. As long as we do not have a shared process against which to weigh the action of group participants, please refrain from accusing active participants of being unfair or the likes.

This PR is evidently unlikely to get significant consensus but it is still an attempt - and the only attempt so far - at laying down some more formal process. I'm not going to merge this, obviously, but discussing its pros and cons is a good idea as it will inform further PRs attempting to do the same. I'm working on one such PR right now but I can't thank @csarven enough for being proactive and suggesting a way forward.

Let's also be more precise with our vocabulary, taking care of separating concepts like opening a new branch, opening a PR, merging and so on.

[melvincarvalho]

@jacoscaz, @csarven, @TallTed, thank you so much for dedicating your time to this. Today, on the 12th anniversary of WebID, I am reminded of our journey so far and how much more unites us than divides us. We all strive for the same goal: a successful WebID. While I didn't agree with the original formulation, it has been tremendously helpful in guiding our iterations. Let's dedicate this year to collaborative efforts to realize the full potential of WebID, honoring the memory of those who put forth our foundations, but are no longer with us to see it.

[jacoscaz]

/chair hat on

Closing as superseded by #48 , which doesn't change our process but simply documents it for what it is right now. Changes to process, particularly if contentious, should be added on top of that and through a dedicated PR per each change.