- From: Marcos Caceres <w3c@marcosc.com>
- Date: Wed, 29 Feb 2012 11:31:35 +0000
- To: Tobie Langel <tobie@fb.com>
- Cc: public-coremob@w3.org
Hi Tobie, Thanks for putting out the charter! Here are some comments… On Wednesday, 29 February 2012 at 11:15, Marcos Caceres wrote: > Core Mobile Web Platform Community Group Charter > Goals > > The goal of the Core Mobile Web Platform Community Group (CG) is to accelerate the adoption of the Mobile Web as a compelling platform for the development of modern mobile web applications. Please drop the word "modern". It applies to all web applications ("modern" is about as meaningful as "native" :) ). > In order to achieve this mission, the CG will bring developers, equipment manufacturers, browser vendors, operators and other relevant members of the industry together to: will bring -> brings together > > Agree on core features developers can depend on. I would add "Research and" to the start of the above. Also, I think it should be defined in terms of "use cases", not features. > These will be defined by reference to a variety of other specifications from the W3C and other standards bodies. This seems kinda wrong… the problem, in my experience, is that there are gaps in the standards landscape itself to do certain things *as well as* in the specs. > Compile related conformance test suites. Compile is confusing… maybe say "create"? > Provide to W3C (and non-W3C) groups use cases, scenarios, and other input to drive successful mobile deployment. Good :) > > Deliverables > > The CG will produce the following types of deliverables: > > Specifications > The CG will develop a series of specifications which combine core features from web standard specifications by the W3C and other standards bodies. Multiple levels of the specification will be published and each successive level will build on the previous one by adding new features. I think it is premature to make the above assumption about how the group will create standards. We should first outline what the problems are, then come up with the most appropriate way to solve those problems. > All normative content will be specified exclusively by reference to the original standard defining the feature. Additional non-normative implementation guidance may be included. Because the Contributor License Agreement (CLA) states that material included by reference does not constitute Essential Claims, there will be no new patent licensing commitments for participants of this group. The community may suggest these specifications be taken up on the W3C standards track. > Test suites > High-quality, comprehensive and automated test suites are important interoperability drivers. The CG will compile accompanying test suites for each specification it releases. How will the CG assess "high-quality"? > Where appropriate, the test suites will draw on pre-existing tests developed for the feature’s original specification. Since test case development may drive normative changes or clarifications into the original specifications, any new tests will be contributed back to the appropriate W3C (or non-W3C) group. > Tests will be contributed to this CG under the “Policies for Contribution of Test Cases to W3C”. Test suites will be distributed under the “Licenses for W3C Test Suites”. > Guidance and Use Cases for other W3C (or non-W3C) groups > Since participants will reflect diverse interests within the mobile ecosystem, the CG plans to document a variety of (non-normative) use cases, scenarios, and other inputs. These may serve as input to other W3C (or non-W3C) groups. > Indicative criteria for the inclusion of features in the Specification > > These are some of the indicative criteria which the CG will use to select features to be included in the Specification: > > The feature is already widely deployed, > It is necessary for building a class of applications that has significant market share in native mobile environments, "native", BINGO! :) > It significantly improves performance across a variety of applications, or > It significantly lowers developer cost. > > > Features whose implementation is compromised by substantial obstacles (such as known security problems or patent licensing issues) will very likely not be included in a specification until the issues have been resolved. Won't the specification help resolve those? For example, putting a proposal to a WG that includes the IP owner on how to fix those issues. > The CG will aim to carefully balance developer needs and implementation constraints to ensure timely progress of the Specification. > > Decision policy > > The decision policy is as follows: > > Chair puts a question. > Chair endeavors to make decisions by consensus but is empowered to make decisions even where there are objections. > Chair has responsibility to ensure that all questions put to the group, all decisions, and all objections are publicly documented. > People who have material new information may request the Chair reopen a question. Editor lacking from the decision policy? > It is the Chair’s responsibility to ensure that the decision process is fair and does not unreasonably favor or discriminate against any group participant or their employer. Sounds good… -- Marcos Caceres http://datadriven.com.au On Tuesday, 28 February 2012 at 19:13, Tobie Langel wrote: > Hi, Just a quick post to let you know I've just added the group's Charter. > --tobie > > > > ---------- > > This post sent on Core Mobile Web Platform Community Group > > > > 'Charter' > > http://www.w3.org/community/coremob/2012/02/28/charter/ > > > > Learn more about the Core Mobile Web Platform Community Group: > > http://www.w3.org/community/coremob
Received on Wednesday, 29 February 2012 11:32:29 UTC