Talk:Viewpoint Advocacy Groups

Naming of VAGs or VATs

• 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 task groups, 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 groups 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)

• I've just realized that we're editing in User:Gigs space at the moment. You might as well promote it to main namespace. It's not like on Wikipedia where you'll get 500 people screaming blue murder at you. ;-))) There weren't any dissenting voices in the AWGroupies chat against this, nor competing ideas. --Morgaine Dinova 08:54, 13 October 2007 (PDT)

• It was moved from V.A.G. to V.A.T. back to V.A.G., which shows a concern. Also, Gigs stated below "These aren't tasks" where in group chat I thought we agreed on the task perspective. That doesn't seem true (anymore?). This seems like the best place to work with this idea. We've had other pages moved to users pages on this wiki, so this is doing just likewise. Dzonatas Sol 09:22, 13 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)

• I support these well-focussed viewpoint groups because they can help reduce arguing over a single spec document, and therefore raise the spirit of collaboration. :-)

As you say, it can be seen as slightly adversarial, but I put quite a different slant on it because of my past history: engineering requirements are ALWAYS in conflict with each other, and therefore require cooperative assessment and calm, professional tradeoffs to be made. These viewpoint groups allow us to approach that structurally, but only if the structure is flat and the playing field level. One issue illustrates this: we've already seen some people express that their concerns and work are so "core" that they don't even need to describe a viewpoint because "core" overrides everything else. That approach does not create an atmosphere of collaboration, which is why I want everyone to buy into your idea rather than consider themselves above it. --Morgaine Dinova 07:58, 13 October 2007 (PDT)

Nothing is above the VAGs. The VAGs will review the work output of the core group in every way. If the core group is proposing something that a particular VAG can come up with a coherent critique on, then that should be reexamined. Gigs Taggart 22:57, 13 October 2007 (PDT)

• Sounds fine to me then Gigs. :-) If nothing is above the VAGs, then "core" must either have no hard design issues associated with it at all (since it involves no concerns/tradeoffs), or else it must be a VAG since it will necessarily express a viewpoint. :-) --Morgaine Dinova 01:08, 14 October 2007 (PDT)

• There are still concerns here that have not been addressed. If the "calm, professional tradeoffs to be made" are to ignore views as done here then how can we expect these groups to fulfill the overall requirements? How can we expect them to even fulfill the goals listed on the article when the implementation of these VAGs don't even follow such viewpoint design? We can't expect that. Again, I reiterate the need to avoid any kind of politics here by these groups. We already found problems in attempts to go forward with the current VA-groups. There is lots of thoughtful work being done that I hate to see go to waste by being misdirected or being too limited. We need a simple flat foundation to begin. Let the elements of the foundation not be limited by these groups. I understand the concern over one large group, and we obviously agree there needs to be a way to break it down. I believe it can be done by more technological method than by a need to form these subgroups. Dzonatas Sol 08:22, 18 October 2007 (PDT)

• Dzon, I agree 100% with the goals that you mention above ... yet I can't find anything here in conflict with those goals! Surely the huge problem isn't merely "group" vs "task"? I was happy with it reverting to VAG after the change to VAT because it makes no actual difference to what we're doing --- we're still going to define the viewpoints, regardless of whether this has a group or a task focus. They're two sides of the same coin, as I see it. :-) --Morgaine Dinova 13:44, 18 October 2007 (PDT)

• If you remember, Gigs even stated in group chat that this being a wiki and feel free to edit it instead of any statement to address the concerns, and that is exactly what occurred here. It was edited to express the concerns. AWG is already a "group." There is no clear viewpoint or clear view to why we need specific subgroups. The subgroups, as suggested by VAG structure, create potential politicization. I also addressed further concerns about that in the above paragraph. Where is the viewpoint that created this VAG implementation? Where do you see "core AWG" defined and why needs there be a "core AWG"? Are they a self appointed group or who appointed them or is all members "core"? I can think of several questions to ask. How are resources set up for these subgroups? What happens when a viewpoint spans several concerns from several groups? Where is the JIRA resource to individualize each issue? ...? We can create viewpoints without subgroups, but if there is a need for a subgroups then "eat your own dog food" and start with the viewpoint/use case for it and address the concerns. I also suggested on the AWG Process talk page to setup "office hour" style times that would be friendly to specific geographical area, and let those discussions work with those agendas. Dzonatas Sol 14:36, 18 October 2007 (PDT)

• I'll ignore the Office Hours timetabling here, not because it's unimportant but because that's a matter for each subgroup to define since it is a function of where their members happen to live. The ability to timetable in a manner that satisfies everyone in a group is inversely proportional to the size of the group, which is a small but not insignificant benefit of subgrouping.
• I'll try to answer your other questions though:

• AWG is certainly a group, but it's a group with such a broad remit that it functions poorly without paritioning, which I'll explain in relation to your second point.
• Your claim that "There is no clear viewpoint or clear view to why we need specific subgroups" is quite wrong: the need for subgrouping emerged out of a direct and very overt requirement. AWG started off without subgroups, and this led to a considerable amount of heat and near warfare as a result of the very different viewpoints and interests of the participants. We expressly chose to subgroup along viewpoint lines to avoid this problem, which was quite literally destroying collaboration as well as wasting everyone's time in the IM channel. That was the reason why, and it was exceedingly important.
• Re politization, VAGs don't add any more of it: at the end of the day, every non-trivial project has conflicting requirements, and they need to be reconciled in a satisfactory engineering manner through tradeoffs. The benefit of subgrouping however is that this difficult process only happens after the concerns have been well quantified, whereas without subgrouping you end up with the same discussions throughout the whole project and before anyone really knows in depth what they're talking about.
• The viewpoint that created this viewpoint system doesn't exist because we picked the nearest solution to hand that addressed our (rather bad) problem. Rather than getting involved in more divisive discussions, we coopted the basic elements of IEEE-1471 as several people seemed happy with them, and nobody else offered any alternatives. There wasn't a conspiracy nor a diktat. :-)
• I have no idea what "core AWG" means, nor what it's meant to accomplish, nor how it can do anything but cause division. The VAG model simply puts everyone's concerns into their own viewpoint groups, including those people who may have considered themselves to be "core" and thus special. With VAGs they are no longer special, yet their concerns are still met. Everyone wins.

• I can't really comment on the other issues. I am however concerned that we're spending so much wiki time on metadiscussions. VAGs aren't perfect, but they're adequate. I don't see a big problem. --Morgaine Dinova 19:23, 18 October 2007 (PDT)

More on groups vs tasks

• The implementation of these VAGs need their own viewpoint and views (not the suggested views/viewpoints from the VAG itself); however, the concerns listed on the VAG page have not been addressed. That already sets a bad example for any future views. The design and model of these VAGs just have not been completed because concerns have been ignored. Dzonatas Sol 07:43, 18 October 2007 (PDT)

• Transplanted from the main namespace of Quality Assurance VAG, where it was clearly off topic since it is not a concern within that viewpoint. It's a good point, but made in the wrong place. This would appear to be the most suitable location. --Morgaine Dinova 13:33, 18 October 2007 (PDT)
• Dzon, I didn't see your last entry in the section above, or I would have responded, sorry. As you can see in the section above though, I don't actually understand the problem that you're highlighting. I do want to. :-) The actual VAG work seems to be progressing smoothly, and I can't see any structural faults with it yet. Maybe you could describe the problem you see in the context of an existing VAG, as an illustration? --Morgaine Dinova 14:03, 18 October 2007 (PDT)

"Eat your own dog food"

I can already see the politics started with "groups" and this is one area we don't need those kind of politics. Even as Rob suggested that LL does not have the means to facilitate. If you want groups Gigs, I suggest you document this more -- "eat your own dog food." I believe there is enough on the front article to know what to include when you write your viewpoint. At this time it is not complete enough, and it be better to have more to understand each other rather than wheel war about it. I think I've written more on this discussion than what you wrote in the article, and maybe that should say something in itself, especially if I continued into further details. I'm looking for your details of your viewpoint. What I changed into "tasks" is the attempt to use modern technology that is already provided to achieve the same goal without the politics, but you don't see that. Dzonatas Sol 07:44, 13 October 2007 (PDT)

• I don't mind either way. The viewpoints are the central idea here (and I didn't invent that). Of course the people gathered around a viewpoint form a group. And what they do is a task. But it's not worth arguing about the name. Just get everyone to subscribe to one or more viewpoints (very lightweight!!), and all will be fine. :-) --Morgaine Dinova

• Yes, it can be very simplified in that view. Modern technology allows easy subscription and *bam* you have the groups automatically behind it. I see no reason to actually define the groups, but there is reason to define the tasks and worry about cost. Dzonatas Sol 08:09, 13 October 2007 (PDT)

• Good point about cost. I'll add that to the general template that's emerging for defining viewpoints. "Regions on Mars" might denote an interesting viewpoint, but its cost field might have some bearing on its viability. ;-))) --Morgaine Dinova 08:18, 13 October 2007 (PDT)