Attribution Guidelines

[eddie-knight]

This will close #1328.

[netlify]

✅ Deploy Preview for tag-security ready!

Name	Link
🔨 Latest commit	c3a104e
🔍 Latest deploy log	https://app.netlify.com/sites/tag-security/deploys/669e86308a4473000868c4df
😎 Deploy Preview	https://deploy-preview-1330--tag-security.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[JustinCappos]

No offense to anyone involved, but my sense is we may have passed the point of useful discourse on this issue.

I propose that we merge this with a caveat that these are guidelines meant to be followed. I'm also open to someone else chiming in with a way to close the issue and move on to other things. :)

[matthewflannery]

No offense to anyone involved, but my sense is we may have passed the point of useful discourse on this issue.

I propose that we merge this with a caveat that these are guidelines meant to be followed. I'm also open to someone else chiming in with a way to close the issue and move on to other things. :)

I feel like the best path is closing this issue by not merging it :D This implies mistrust, rather than trusting people won't misattibuted or misrepresent the group which no one ever has to my knowledge?

Considering after all that this is open source software we are effectively talking about, shouldnt the goal be to encourage people to participate rather than creating rules for the sake of rules? It's hard enough for people to find time in their busy lives to volunteer expertise.

@eddie-knight is there any major benefit to this otherwise? Is CNCF or TAG Security at risk by not merging this in?

[mnm678]

Does this mean that a presentation would have to be approved every time someone gives a shout out to TAG Security? For example in the lead-up to CloudNativeSecurityCon I gave several explanations of what the TAG does, etc, which I would not have been able to do if it required an approval process.

[eddie-knight]

We could modify the second point below to use a type of "lazy consensus" language, but I imagine that yes— we would want to have some reasonable ability for leads to ensure that content is up to date before it is presented to the public as representative of the group.

For example, if @sublimino does a presentation about the TAG (as he often does), we should have a process that he can easily follow to help him share the latest from the group.

But if @sublimino was doing a presentation about his experience in the TAG (not representing the group) then it wouldn't benefit from the additional support layer.

[mnm678]

Another possible path forward would be to merge a more general form of this guidance that describes the intention of the policy (what's in the first paragraph), without setting specific requirements for types of publications, leaving us the flexibility to use our best judgement.

[anvega]

A general form of the guidance already exists in the Code of Conduct, which covers what constitutes work that belongs to the group. The spirit of what is proposed here is contradictory to that.

Work performed within this group, either finalized or in draft, is to be used in accordance with the group Mission and Charter, the open source license, and to be used for the equal benefit of all members of the community. Further information on the use of work may be found in Security Reviews: Outcome.

Moreover, basing these guidelines on publication checklists, which I wrote for ebook material, will add toil to individuals giving presentations and other actitivies just as @mnm678 mentions.