Difference between revisions of "Talk:Viewpoint Advocacy Groups"
Rob Linden (talk | contribs) (→Groups: my L$2) |
Dzonatas Sol (talk | contribs) m (Talk:Viewpoint Advocacy Groups moved to User talk:Gigs Taggart/Viewpoint Advocacy Groups: The page here may be confused with official policy.) |
(No difference)
|
Revision as of 07:34, 13 October 2007
- I am actually very serious about the slight rename of V.A.G. to V.A.T., as light-handedly discussed on the group chat. Dzonatas Sol 16:13, 11 October 2007 (PDT)
- Could you elaborate on the reason for the name change? I see the comment "to keep focus of the right direction, keep in mind about COST, and avoid bureaucracy" but don't quite understand how the name change accomplishes this. --Burhop Piccard 17:56, 11 October 2007 (PDT)
- It implies a meaning from recent events, which are significant; however, the name change alone is not a complete solution. It is a minimal change to influence the discussion. The serious point being task focused and cost effective. The Tao Of Linden already points out the need to not be political. Zero also reiterated about the need to have no ego in code. The emphasis of "groups" and "core AWG" can easily be a politicized medium, and we want to avoid that. We need to stay a team altogether. In AWG chat, we found the intention is not to actually form (sub)groups, but the intent is more to (to quote the article), "Document rationale for architectural decisions" and "Work with the core goals to document views and requirements that conflict or are inconsistent." It is inconsistent and political to form more subgroups to do what the AWG already does. JIRA is an example of a better medium then subgroups -- create tasks and subtasks. Again, COST is not something I've seen discussed. COST is an influence here. In fact, a good example of a use case is the recent event between Europe and non-EU currency transactions. Hmm, what's a good way to say it with too many details... look at ArchWG_Mtg_1_Slides and create an analogy of "mainland" to the U.S. -- and remember that the pipe between US and EU is limited. Then you'll get the notion that the "V.A.G." (as previous defined) IS the AWG. The question becomes, why change it from "A.W.G" to "V.A.G."? Dzonatas Sol 19:07, 11 October 2007 (PDT)
- I very much support the idea of working on tasks, rather than belonging to a group. I intend to work on (or have an interest in) numerous tasks, maybe all of them to some degree, so group membership isn't a very helpful concept in this. --Morgaine Dinova 23:21, 11 October 2007 (PDT)
- Dzonatas' point about "groups" vs "core AWG" potentially creating a dangerous politization is very important. By placing all concerns into their own VA Tasks, including those who some feel are "core", the entire structure is flattened and all choices have to be justified equally. The "core" tasks (and the people working on them) will then no longer be special, but simply represent those concerns that we have agreed on a priori, like using REST. This is a much cleaner and less adversarial project structure, in my view. --Morgaine Dinova 23:32, 11 October 2007 (PDT)
Groups
To be clear, we ARE talking about groups here. We have groups of stakeholders with their own concerns. These aren't tasks, they are groups.
You all mention "politicization" ... Groups of people will want certain things, depending on what their stake is. Trying to deny that is just going to lead to a lot of useless bickering. This is supposed to be a framework for various groups to advocate their viewpoint and to ensure that their requirements are met as best we can.
It's supposed to be slightly adversarial, in the same sense that a prosecuting attorney and a defense attorney are adversarial. It doesn't mean they can't go have dinner together after the trial, or even switch roles in the next trial. We are all working toward the same end, but that doesn't mean we all need to advocate the same viewpoints.
Membership in one of these groups isn't exclusive, and there's no reason one person can't be a member of more than one group, or a member of one of these groups and also of the core team. In that sense it isn't polarizing, since there's nothing preventing participation anywhere that someone wants to participate. It's merely a construct to provide a way of thinking about stakeholder groups, their needs, and integrate them into the design.
I'm renaming this back to groups.
Gigs Taggart 11:47, 12 October 2007 (PDT)
- These groups should have their own meetings, and produce their own output. This allows for a finer grained focus than one huge group with many stakeholders all trying to pull the group in their own direction. I expect most of these subgroups to be from 3-7 people. This is an ideal size for actually getting things accomplished. Larger groups are REALLY BAD at getting anything done. Gigs Taggart 11:58, 12 October 2007 (PDT)
I think this is a fine idea. I like the idea of having organized groups feed in specific use cases and requirements, rather than a central group needing to do a ton of heavy lifting. I don't think Linden Lab can facilitate all of this, but we certainly don't want to obstruct it. -- Rob Linden 12:59, 12 October 2007 (PDT)