Talk:Viewpoint Advocacy Groups - Revision history

Morgaine Dinova: Fixed full/long name of REST Services VAG

2007-11-10T15:34:52Z

Fixed full/long name of REST Services VAG

← Older revision		Revision as of 08:34, 10 November 2007
Line 159:		Line 159:
	:: 3) The move was done without even consulting the members of this VAG nor the members of any VAGs that use it.		:: 3) The move was done without even consulting the members of this VAG nor the members of any VAGs that use it.

	* For the record, stakeholders in the [[Scalability VAG]] and [[Core ~~AWG~~ Services VAG]] propose to use the tools being created for the [[Quality Assurance VAG]] for a number of purposes directly relevant to AWG and intended to increase the quality of AWG efforts. This spans performance, reliability, latency, scalability, testing conformance with VAG viewpoints, generating viewpoint-related architectural descriptions, and others. --[[User:Morgaine Dinova\|Morgaine Dinova]] 07:05, 10 November 2007 (PST)		* For the record, stakeholders in the [[Scalability VAG]] and [[Core Grid Services, Protocols, and Structures VAG]] propose to use the tools being created for the [[Quality Assurance VAG]] for a number of purposes directly relevant to AWG and intended to increase the quality of AWG efforts. This spans performance, reliability, latency, scalability, testing conformance with VAG viewpoints, generating viewpoint-related architectural descriptions, and others. --[[User:Morgaine Dinova\|Morgaine Dinova]] 07:05, 10 November 2007 (PST)

Morgaine Dinova: Moved my misplaced paragraph to end of document

2007-11-10T15:22:40Z

Moved my misplaced paragraph to end of document

@@ Line 35: / Line 35: @@
 [[Image:vag-org2.png | 400 px]] (Note: the red lines are mostly random. I'm not trying to suggest any VAGs here.)  --[[User:Burhop Piccard|Burhop Piccard]] 09:17, 19 October 2007 (PDT)
 :* That's fine by me, Burhop.  It takes us back to where we were initially, where a VAG's concerns may address any area of the system as required, without prior constraints. In other words, system areas are enumerated vertically, and if the list is complete then it serves no purpose since it will then mean "everything", which is correct.  Good luck trying to keep the list complete though. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 09:31, 19 October 2007 (PDT)
 == Viewpoints: the substance behind the concept ==
@@ Line 160: / Line 151: @@
 * Maybe some direct pump priming from Lindens would encourage more AWG people to create VAGs in their special areas of interest, or to join some VAGs as a reference resource for their own work.  We really do need more participation in this process, I couldn't agree more. --[[User:Morgaine Dinova|Morgaine Dinova]] 00:05, 23 October 2007 (PDT)

Morgaine Dinova: /* Organizational structure of VAGs */

2007-11-10T15:05:36Z

Organizational structure of VAGs

← Older revision		Revision as of 08:05, 10 November 2007
Line 35:		Line 35:
	[[Image:vag-org2.png \| 400 px]] (Note: the red lines are mostly random. I'm not trying to suggest any VAGs here.) --[[User:Burhop Piccard\|Burhop Piccard]] 09:17, 19 October 2007 (PDT)		[[Image:vag-org2.png \| 400 px]] (Note: the red lines are mostly random. I'm not trying to suggest any VAGs here.) --[[User:Burhop Piccard\|Burhop Piccard]] 09:17, 19 October 2007 (PDT)
	:* That's fine by me, Burhop. It takes us back to where we were initially, where a VAG's concerns may address any area of the system as required, without prior constraints. In other words, system areas are enumerated vertically, and if the list is complete then it serves no purpose since it will then mean "everything", which is correct. Good luck trying to keep the list complete though. :-) --[[User:Morgaine Dinova\|Morgaine Dinova]] 09:31, 19 October 2007 (PDT)		:* That's fine by me, Burhop. It takes us back to where we were initially, where a VAG's concerns may address any area of the system as required, without prior constraints. In other words, system areas are enumerated vertically, and if the list is complete then it serves no purpose since it will then mean "everything", which is correct. Good luck trying to keep the list complete though. :-) --[[User:Morgaine Dinova\|Morgaine Dinova]] 09:31, 19 October 2007 (PDT)

			== Namespace issues ==
			* The [[Viewpoint Advocacy Groups]] page is not an AWG page but an AWGroupies page and so does not necessarily represent AWG policy. Despite this, and despite this being the only page which lists the VAGs, one of those VAGs ([[Quality Assurance VAG\|QA VAG]]) indexed through this page was moved to a user page (Dzon's), without any discussion nor agreement with AWGroupies nor any indication on Talk pages about the rationale for the move. Presumably this was under the mistaken belief that the page was a Category:AWG page, which it is not, or that the user in question is a stakeholder, which he is not. The move has therefore been reverted, with the following reasons given:

			:: 1) Dzonatas Sol is not even a member of this VAG.
			:: 2) This VAG is a core VAG which factors out tools used in several other AWG VAGs, underpins the measurements and results used in those VAGs, and which generates the ADVs used to describe the viewpoints in those VAGs.
			:: 3) The move was done without even consulting the members of this VAG nor the members of any VAGs that use it.

			* For the record, stakeholders in the [[Scalability VAG]] and [[Core AWG Services VAG]] propose to use the tools being created for the [[Quality Assurance VAG]] for a number of purposes directly relevant to AWG and intended to increase the quality of AWG efforts. This spans performance, reliability, latency, scalability, testing conformance with VAG viewpoints, generating viewpoint-related architectural descriptions, and others. --[[User:Morgaine Dinova\|Morgaine Dinova]] 07:05, 10 November 2007 (PST)

	== Viewpoints: the substance behind the concept ==		== Viewpoints: the substance behind the concept ==

Morgaine Dinova: /* More groups than participants here */

2007-10-23T07:05:02Z

More groups than participants here

← Older revision		Revision as of 00:05, 23 October 2007
Line 144:		Line 144:

	Some churn is to be expected, in a project launched with no formal structures in place. Self organizing isn't pretty, but it's what we're doing. -- [[User:Zha Ewry\|Zha]] 7:16 PM, 22 October, 2007 (PDT)		Some churn is to be expected, in a project launched with no formal structures in place. Self organizing isn't pretty, but it's what we're doing. -- [[User:Zha Ewry\|Zha]] 7:16 PM, 22 October, 2007 (PDT)
			:* Indeed. And it's worth pointing out that we're working hard despite severe IM and wiki lag problems that show no signs of being fixed, because we believe in this project. We're doing our best. -[[User:Morgaine Dinova\|Morgaine Dinova]] 00:05, 23 October 2007 (PDT)

			* The work on VAGs is actually proceeding fairly well, when one considers the limited manpower available. I agree that it's really disappointing that such a small percentage of AWG members are contributing to the wiki, as this puts a large workload on the shoulders of the few that do. Some of the VAGs are so central to the project that it's crucial that we get good representation on them --- in principle almost ''everyone'' in AWG is a stakeholder in the Scalability VAG for example, to varying extents --- but we can't mandate people to join. Community projects tend to be like this, meandering slowly towards an evolving goal, with those putting in the hours pathing the way. It's in the nature of the beast.

			* Three of the VAGs arise from factoring of the problem space through specialization: Scalability -> Event Scalability -> Live Performances. Lumping them together into one huge VAG would not be useful, nor would it be accurate since there is a 1 < N < M relationship between them. (N is up to 4 dimensions of scalability, and M is as many as there are distinct mass event types). Perhaps this didn't come across on a casual reading.

			* Maybe some direct pump priming from Lindens would encourage more AWG people to create VAGs in their special areas of interest, or to join some VAGs as a reference resource for their own work. We really do need more participation in this process, I couldn't agree more. --[[User:Morgaine Dinova\|Morgaine Dinova]] 00:05, 23 October 2007 (PDT)

Zha Ewry: /* More groups than participants here */

2007-10-23T02:18:04Z

More groups than participants here

← Older revision		Revision as of 19:18, 22 October 2007
Line 143:		Line 143:
	* Well.. There's a lot of churn and I think its unclear if all the various groups which have been mentioned are real, or just some people's posting possibilities. I'd much rather sieve groups by results. If one person is passionate about a topic, and getting things done, that's fine with me. That's rather the point of IEEE-1471, that the groupings happen, and should be embraced, not ignored.		* Well.. There's a lot of churn and I think its unclear if all the various groups which have been mentioned are real, or just some people's posting possibilities. I'd much rather sieve groups by results. If one person is passionate about a topic, and getting things done, that's fine with me. That's rather the point of IEEE-1471, that the groupings happen, and should be embraced, not ignored.

	Some churn is to be expected, in a project launched with no formal structures in place. Self organizing isn't pretty, but it's what we're doing. -- [[User:Zha Ewry\|Zha] 7:16 PM, 22 October, 2007 (PDT)		Some churn is to be expected, in a project launched with no formal structures in place. Self organizing isn't pretty, but it's what we're doing. -- [[User:Zha Ewry\|Zha]] 7:16 PM, 22 October, 2007 (PDT)

Zha Ewry: Judge by results, churn is expected

2007-10-23T02:17:21Z

Judge by results, churn is expected

← Older revision		Revision as of 19:17, 22 October 2007
Line 139:		Line 139:
	== More groups than participants here ==		== More groups than participants here ==

	Ok.....this has gotten way out of hand. There are more groups here than participants. Please limit yourself to starting one new VAG per person. Also, I think we should delete VAGs that only have one participant after one month. -- [[User:Rob Linden\|Rob Linden]] 10:56, 22 October 2007 (PDT)		* Ok.....this has gotten way out of hand. There are more groups here than participants. Please limit yourself to starting one new VAG per person. Also, I think we should delete VAGs that only have one participant after one month. -- [[User:Rob Linden\|Rob Linden]] 10:56, 22 October 2007 (PDT)

			* Well.. There's a lot of churn and I think its unclear if all the various groups which have been mentioned are real, or just some people's posting possibilities. I'd much rather sieve groups by results. If one person is passionate about a topic, and getting things done, that's fine with me. That's rather the point of IEEE-1471, that the groupings happen, and should be embraced, not ignored.

			Some churn is to be expected, in a project launched with no formal structures in place. Self organizing isn't pretty, but it's what we're doing. -- [[User:Zha Ewry\|Zha] 7:16 PM, 22 October, 2007 (PDT)

Rob Linden: More groups than participants here

2007-10-22T17:56:32Z

More groups than participants here

← Older revision		Revision as of 10:56, 22 October 2007
Line 136:		Line 136:
	:::::* If I've understood you both, I think there is a question concerning interVAG relations (when VAGs overlap) and subVAGs (special interest group within a subVAG). Organization and comunication of VAGs is important as it affects content of the VAG. As one example of this, a scalability VAG could actually have a facilitor role in helping other VAG address the issue. They might also cover areas where another VAG doen't exist or are unable to handle it.--[[User:Burhop Piccard\|Burhop Piccard]] 17:14, 21 October 2007 (PDT)		:::::* If I've understood you both, I think there is a question concerning interVAG relations (when VAGs overlap) and subVAGs (special interest group within a subVAG). Organization and comunication of VAGs is important as it affects content of the VAG. As one example of this, a scalability VAG could actually have a facilitor role in helping other VAG address the issue. They might also cover areas where another VAG doen't exist or are unable to handle it.--[[User:Burhop Piccard\|Burhop Piccard]] 17:14, 21 October 2007 (PDT)
	::::::* That's certainly how I see it, yes. For me, a technical VAG is a project resource. --[[User:Morgaine Dinova\|Morgaine Dinova]] 19:45, 21 October 2007 (PDT)		::::::* That's certainly how I see it, yes. For me, a technical VAG is a project resource. --[[User:Morgaine Dinova\|Morgaine Dinova]] 19:45, 21 October 2007 (PDT)

			== More groups than participants here ==

			Ok.....this has gotten way out of hand. There are more groups here than participants. Please limit yourself to starting one new VAG per person. Also, I think we should delete VAGs that only have one participant after one month. -- [[User:Rob Linden\|Rob Linden]] 10:56, 22 October 2007 (PDT)

Morgaine Dinova: /* Viewpoints and the inter-VAG reference graph */

2007-10-22T02:45:27Z

Viewpoints and the inter-VAG reference graph

← Older revision		Revision as of 19:45, 21 October 2007
Line 135:		Line 135:

	:::::* If I've understood you both, I think there is a question concerning interVAG relations (when VAGs overlap) and subVAGs (special interest group within a subVAG). Organization and comunication of VAGs is important as it affects content of the VAG. As one example of this, a scalability VAG could actually have a facilitor role in helping other VAG address the issue. They might also cover areas where another VAG doen't exist or are unable to handle it.--[[User:Burhop Piccard\|Burhop Piccard]] 17:14, 21 October 2007 (PDT)		:::::* If I've understood you both, I think there is a question concerning interVAG relations (when VAGs overlap) and subVAGs (special interest group within a subVAG). Organization and comunication of VAGs is important as it affects content of the VAG. As one example of this, a scalability VAG could actually have a facilitor role in helping other VAG address the issue. They might also cover areas where another VAG doen't exist or are unable to handle it.--[[User:Burhop Piccard\|Burhop Piccard]] 17:14, 21 October 2007 (PDT)
			::::::* That's certainly how I see it, yes. For me, a technical VAG is a project resource. --[[User:Morgaine Dinova\|Morgaine Dinova]] 19:45, 21 October 2007 (PDT)

Burhop Piccard: VAG Interactin

2007-10-22T00:14:34Z

VAG Interactin

← Older revision		Revision as of 17:14, 21 October 2007
Line 133:		Line 133:
	::::* And the same applies in reverse. Do you expect people whose special interest and competence and concerns are in Physics Simulation, to duplicate all the work of the REST Services team within the Physics VAG just because they need to be aware of the comms mechanism which underpins services? Of course not. Instead, you expect them to take an interest in the REST Services VAG (or whatever that team calls it) and to import the results of that team into the deliberations of the Physics VAG. It's functional specialization. Likewise the Scalability VAG itself ... we don't intend to duplicate the work of the Physics and REST Services VAGs --- we expect to import the results of their work. Functional specialization.		::::* And the same applies in reverse. Do you expect people whose special interest and competence and concerns are in Physics Simulation, to duplicate all the work of the REST Services team within the Physics VAG just because they need to be aware of the comms mechanism which underpins services? Of course not. Instead, you expect them to take an interest in the REST Services VAG (or whatever that team calls it) and to import the results of that team into the deliberations of the Physics VAG. It's functional specialization. Likewise the Scalability VAG itself ... we don't intend to duplicate the work of the Physics and REST Services VAGs --- we expect to import the results of their work. Functional specialization.
	::::* I really can't understand the basis for an "everyone has to reinvent everything" approach to design. --[[User:Morgaine Dinova\|Morgaine Dinova]] 12:21, 21 October 2007 (PDT)		::::* I really can't understand the basis for an "everyone has to reinvent everything" approach to design. --[[User:Morgaine Dinova\|Morgaine Dinova]] 12:21, 21 October 2007 (PDT)

			:::::* If I've understood you both, I think there is a question concerning interVAG relations (when VAGs overlap) and subVAGs (special interest group within a subVAG). Organization and comunication of VAGs is important as it affects content of the VAG. As one example of this, a scalability VAG could actually have a facilitor role in helping other VAG address the issue. They might also cover areas where another VAG doen't exist or are unable to handle it.--[[User:Burhop Piccard\|Burhop Piccard]] 17:14, 21 October 2007 (PDT)

Morgaine Dinova: /* Viewpoints and the inter-VAG reference graph */

2007-10-21T19:21:49Z

Viewpoints and the inter-VAG reference graph

← Older revision		Revision as of 12:21, 21 October 2007
Line 129:		Line 129:
	::Why don't we introduce a new concept then, the "cross-cutting issue". A cross-cutting issue would be off limits in terms of creating an explicit VAG for it, but every VAG would be required to examine their output's impact on each cross cutting issue? [[User:Gigs Taggart\|Gigs Taggart]] 18:58, 20 October 2007 (PDT)		::Why don't we introduce a new concept then, the "cross-cutting issue". A cross-cutting issue would be off limits in terms of creating an explicit VAG for it, but every VAG would be required to examine their output's impact on each cross cutting issue? [[User:Gigs Taggart\|Gigs Taggart]] 18:58, 20 October 2007 (PDT)
	::* You can't have individual "issues" appearing from thin air, they need justification somewhere. That's why issues are first analyzed thoroughly in end-user VAGs by end-user stakeholders in the context of all the relevant areas simultaneously, which gives them justification, and are then presented as fully baked concerns for other VAGs to take as requirements and constraints. That analysis can't be done in the technical VAGs because those try to focus on one area at a time, whereas end-user VAGs will in almost all cases have concerns that span numerous areas simply because normal user activity usually spans numerous areas. As I explained [[Talk:Viewpoint Advocacy Groups#Viewpoints: the substance behind the concept\|further up]], it's fundamental to the viewpoint concept that each set of stakeholders has to define and extract its own [[Architecture_Working_Group_Glossary#Architectural_descriptions_and_views_.28ADV.29\|ADV]]s, because this is how the architecture expresses its conformance with their concerns. No other VAG can do that for them, because no other VAG has their scope and concerns. --[[User:Morgaine Dinova\|Morgaine Dinova]] 01:03, 21 October 2007 (PDT)		::* You can't have individual "issues" appearing from thin air, they need justification somewhere. That's why issues are first analyzed thoroughly in end-user VAGs by end-user stakeholders in the context of all the relevant areas simultaneously, which gives them justification, and are then presented as fully baked concerns for other VAGs to take as requirements and constraints. That analysis can't be done in the technical VAGs because those try to focus on one area at a time, whereas end-user VAGs will in almost all cases have concerns that span numerous areas simply because normal user activity usually spans numerous areas. As I explained [[Talk:Viewpoint Advocacy Groups#Viewpoints: the substance behind the concept\|further up]], it's fundamental to the viewpoint concept that each set of stakeholders has to define and extract its own [[Architecture_Working_Group_Glossary#Architectural_descriptions_and_views_.28ADV.29\|ADV]]s, because this is how the architecture expresses its conformance with their concerns. No other VAG can do that for them, because no other VAG has their scope and concerns. --[[User:Morgaine Dinova\|Morgaine Dinova]] 01:03, 21 October 2007 (PDT)
	:::There are some issues that are clearly cross-cutting. Scalability, security, possibly more. These are not things that can be designed in a vacuum. Every group must consider scalability and security issues as their output. You can't just design that stuff in a single subgroup, it's got to be part of everything. [[User:Gigs Taggart\|Gigs Taggart]] 07:19, 21 October 2007 (PDT)		:::*There are some issues that are clearly cross-cutting. Scalability, security, possibly more. These are not things that can be designed in a vacuum. Every group must consider scalability and security issues as their output. You can't just design that stuff in a single subgroup, it's got to be part of everything. [[User:Gigs Taggart\|Gigs Taggart]] 07:19, 21 October 2007 (PDT)
			::::* Which is precisely why there is a central Scalability VAG, so that everyone who has an interest in scalability (which is almost everybody) can discuss scalability under a well defined terms of references, instead of everyone reinventing it themselves and doing it their own way, badly. You can't expect every VAG to go into scalability in the same depth as the Scalability VAG. You can't expect them all to create tools to describe and to measure scalability. You can't expect them all to know and employ suitable analysis techniques for scalability --- it's a very specialist area. That's why, while almost everybody needs to keep scalability in the back of their minds, the key work is done in the Scalability VAG, and they each take the results of that work back into their own VAGs. It's functional specialization.
			::::* And the same applies in reverse. Do you expect people whose special interest and competence and concerns are in Physics Simulation, to duplicate all the work of the REST Services team within the Physics VAG just because they need to be aware of the comms mechanism which underpins services? Of course not. Instead, you expect them to take an interest in the REST Services VAG (or whatever that team calls it) and to import the results of that team into the deliberations of the Physics VAG. It's functional specialization. Likewise the Scalability VAG itself ... we don't intend to duplicate the work of the Physics and REST Services VAGs --- we expect to import the results of their work. Functional specialization.
			::::* I really can't understand the basis for an "everyone has to reinvent everything" approach to design. --[[User:Morgaine Dinova\|Morgaine Dinova]] 12:21, 21 October 2007 (PDT)

← Older revision		Revision as of 12:21, 21 October 2007
Line 129:		Line 129:
	::Why don't we introduce a new concept then, the "cross-cutting issue". A cross-cutting issue would be off limits in terms of creating an explicit VAG for it, but every VAG would be required to examine their output's impact on each cross cutting issue? [[User:Gigs Taggart\|Gigs Taggart]] 18:58, 20 October 2007 (PDT)		::Why don't we introduce a new concept then, the "cross-cutting issue". A cross-cutting issue would be off limits in terms of creating an explicit VAG for it, but every VAG would be required to examine their output's impact on each cross cutting issue? [[User:Gigs Taggart\|Gigs Taggart]] 18:58, 20 October 2007 (PDT)
	::* You can't have individual "issues" appearing from thin air, they need justification somewhere. That's why issues are first analyzed thoroughly in end-user VAGs by end-user stakeholders in the context of all the relevant areas simultaneously, which gives them justification, and are then presented as fully baked concerns for other VAGs to take as requirements and constraints. That analysis can't be done in the technical VAGs because those try to focus on one area at a time, whereas end-user VAGs will in almost all cases have concerns that span numerous areas simply because normal user activity usually spans numerous areas. As I explained [[Talk:Viewpoint Advocacy Groups#Viewpoints: the substance behind the concept\|further up]], it's fundamental to the viewpoint concept that each set of stakeholders has to define and extract its own [[Architecture_Working_Group_Glossary#Architectural_descriptions_and_views_.28ADV.29\|ADV]]s, because this is how the architecture expresses its conformance with their concerns. No other VAG can do that for them, because no other VAG has their scope and concerns. --[[User:Morgaine Dinova\|Morgaine Dinova]] 01:03, 21 October 2007 (PDT)		::* You can't have individual "issues" appearing from thin air, they need justification somewhere. That's why issues are first analyzed thoroughly in end-user VAGs by end-user stakeholders in the context of all the relevant areas simultaneously, which gives them justification, and are then presented as fully baked concerns for other VAGs to take as requirements and constraints. That analysis can't be done in the technical VAGs because those try to focus on one area at a time, whereas end-user VAGs will in almost all cases have concerns that span numerous areas simply because normal user activity usually spans numerous areas. As I explained [[Talk:Viewpoint Advocacy Groups#Viewpoints: the substance behind the concept\|further up]], it's fundamental to the viewpoint concept that each set of stakeholders has to define and extract its own [[Architecture_Working_Group_Glossary#Architectural_descriptions_and_views_.28ADV.29\|ADV]]s, because this is how the architecture expresses its conformance with their concerns. No other VAG can do that for them, because no other VAG has their scope and concerns. --[[User:Morgaine Dinova\|Morgaine Dinova]] 01:03, 21 October 2007 (PDT)
	:::There are some issues that are clearly cross-cutting. Scalability, security, possibly more. These are not things that can be designed in a vacuum. Every group must consider scalability and security issues as their output. You can't just design that stuff in a single subgroup, it's got to be part of everything. [[User:Gigs Taggart\|Gigs Taggart]] 07:19, 21 October 2007 (PDT)		:::*There are some issues that are clearly cross-cutting. Scalability, security, possibly more. These are not things that can be designed in a vacuum. Every group must consider scalability and security issues as their output. You can't just design that stuff in a single subgroup, it's got to be part of everything. [[User:Gigs Taggart\|Gigs Taggart]] 07:19, 21 October 2007 (PDT)
			::::* Which is precisely why there is a central Scalability VAG, so that everyone who has an interest in scalability (which is almost everybody) can discuss scalability under a well defined terms of references, instead of everyone reinventing it themselves and doing it their own way, badly. You can't expect every VAG to go into scalability in the same depth as the Scalability VAG. You can't expect them all to create tools to describe and to measure scalability. You can't expect them all to know and employ suitable analysis techniques for scalability --- it's a very specialist area. That's why, while almost everybody needs to keep scalability in the back of their minds, the key work is done in the Scalability VAG, and they each take the results of that work back into their own VAGs. It's functional specialization.
			::::* And the same applies in reverse. Do you expect people whose special interest and competence and concerns are in Physics Simulation, to duplicate all the work of the REST Services team within the Physics VAG just because they need to be aware of the comms mechanism which underpins services? Of course not. Instead, you expect them to take an interest in the REST Services VAG (or whatever that team calls it) and to import the results of that team into the deliberations of the Physics VAG. It's functional specialization. Likewise the Scalability VAG itself ... we don't intend to duplicate the work of the Physics and REST Services VAGs --- we expect to import the results of their work. Functional specialization.
			::::* I really can't understand the basis for an "everyone has to reinvent everything" approach to design. --[[User:Morgaine Dinova\|Morgaine Dinova]] 12:21, 21 October 2007 (PDT)