-
Notifications
You must be signed in to change notification settings - Fork 518
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify TAG attribution policies #1328
Comments
Just adding my 2 cents: I'd argue that if we brand something as being from the group, it needs to be discussed on a channel and in a timeframe appropriate for the content. So, obviously a blog post from the group might require 2-3 folks to sign off and be relatively quick. A book or flagship TR would need a lot more scrutiny and time. If it's 'by someone who happens to have some affiliation, including TAG-Security', then I don't see why the group would need to review it. This might be done as a courtesy. However, for example, NYU doesn't review everything I say or do before I do so. We're all experts in the field and should be able to comment freely as ourselves without needing consensus. I'm in favor of us trying to feel out in the group what timeframe makes sense and to keep this as a guideline, not a hard rule to be strictly enforced. Situations arise that may cause us to want to move faster or slower. I've been in groups where effectively the rules become a stick to wield to try to stymie people or efforts we're not fully on board with. Let's not become that group ourselves. 😄 Overall, I think it's key we do everything on a channel where others are aware of what is happening to the extent that is practical. It's hard to work together if we're not communicating. |
If this is the current state, I don't think there's anything we can do to change that. 😅 I'm not sure that a reasonable person is going to take the time and effort to dig through the results of this issue and subsequent documentation (no matter where it lives) to understand the "appropriate" attribution.
The word choices of
I don't think they can. And really, the member represents more than just the TAG. We are nominated by the TAG but, approved by the TOC. Our actions are a reflections of those decisions on behalf of the TAG, the TOC, and by proxy the CNCF (which elects and appoints the TOC).
My assumption is that the byline would only include "CNCF Security TAG". Additionally the inclusion of all the current Chairs and TLs at the time of publication could be listed for more specific attribution. |
There are two places where this topic has come up recently: whitepapers and blogs. The linked PR addresses all of the situations I could think of, and includes examples for how to reference a TAG role without leaving room for mistaken attribution to the group as a whole. |
I agree with what Justin wrote. This issue seems unnecessary. Having worked in Government, Defence and Banks I can relate extensively to how less of these rules are better if it is innovation being sought. |
Given that we have existing processes for both blog posts and publications, the only open question seems to be resources published to external sites. I think this can be handled by the TAG leadership with "reasonable communication" on an as-needed basis in accordance with our charter to prevent creating too many hoops for opportunities to market the TAG and its work. Given that, and the disagreement about how specific an attribution policy should be, I'm going to close this for now pending future consensus. |
This relates to #1321 as well as #1311.
Currently, a reasonable person can draw different conclusions as to when and how TAG Security can be attributed.
For example, whitepapers, public statements, project communications, STAG website blogs, and other blogs.
The text was updated successfully, but these errors were encountered: