[webkit-dev] WebKit Project Goals

[Benjamin Hawkes-Lewis]

Would it not be worth making an explicit goal of accessibility, or at
least explicitly bracketing it under usability?

--
Benjamin Hawkes-Lewis

On 7/25/07, Maciej Stachowiak <mjs at apple.com> wrote:
>
> I sent this a while ago with not much comment. Any thoughts? Should I
> post this on webkit.org somewhere?
>
>   - Maciej
>
> On May 10, 2007, at 3:34 PM, Maciej Stachowiak wrote:
>
> >
> > Hi Everyone,
> >
> > I recently watched a video on the topic of preventing poisonous
> > people from hurting an open source project. One of the practices it
> > recommends for a large open source project is to have a "mission
> > statement", so it's clear to everyone what is and isn't in scope for
> > the project. I'm not too fond of the name "mission statement" (it
> > sounds a little corporate) but I do think it's important to write
> > down our goals as a project.
> >
> > Ultimately I'd like to put this on the WebKit site, but I wanted to
> > throw out some ideas for discussion. I'd like to hear if anyone
> > thinks I have missed any project goals, if any of these are worded
> > badly, or if it is worth calling out more non-goals.
> >
> >
> > WebKit Project Goals
> >
> > WebKit is an open source Web content engine for browsers and other
> > applications. We value real-world web compatibility, standards
> > compliance, stability, performance, security, portability, usability
> > and relative ease of understanding and modifying the code
> > (hackability).
> >
> > Web Content Engine - The project's primary focus is content deployed
> > on the World Wide Web, using standards-based technologies such as
> > HTML, CSS, JavaScript and the DOM. However, we also want to make it
> > possible to embed WebKit in other applications, and to use it as a
> > general-purpose display and interaction engine.
> >
> > Open Source - WebKit should remain freely usable for both open
> > source and proprietary applications. To that end, we use BSD-style
> > and LGPL licenses.
> >
> > Compatibility - For users browsing the web, compatibility with their
> > existing sites is essential. We strive to maintain and improve
> > compatibility with existing web content, sometimes even at the
> > expense of standards. We use regression testing to maintain our
> > compatibility gains.
> >
> > Standards Compliance - WebKit aims for compliance with relevant web
> > standards, and support for new standards
> > In addition to improving compliance, we participate in the web
> > standards community to bring new technologies into standards, and to
> > make sure new standards are pratical to implement in our engine. We
> > use regression testing to maintain our standards compliance gains.
> >
> > Stability - The main WebKit code base should always maintain a high
> > degree of stability. This means that crashes, hangs and regressions
> > should be dealt with promptly, rather than letting them pile up.
> >
> > Performance - Maintaining and improving speed and memory use is an
> > important goal. We never consider performance "good enough", but
> > strive to constantly improve. As web content becomes richer and more
> > complex, and as web browsers run on more limited devices,
> > performance gains continue to have value even if normal browsing
> > seems fast enough.
> >
> > Security - Protecting users from security violations is critical. We
> > fix security issues promptly to protect users and maintain their
> > trust.
> >
> > Portability - The WebKit project seeks to address a variety of
> > needs. We want to make it reasonable to port WebKit to a variety of
> > desktop, mobile, embedded and other platforms. We will provide the
> > infrastructure to do this with tight platform integration, reusing
> > native platform services where appropriate and providing friendly
> > embedding APIs.
> >
> > Usability - To the extent that WebKit features affect the user
> > experience, we want them to work in accordance with good human
> > interface design principles, and to mesh well with platform-native
> > HI conventions.
> >
> > Hackability - To make rapid progress possible, we try to keep the
> > code relatively easy to understand, even though web technologies are
> > often complex. We try to use straightforward algorithms and data
> > structures when possible, we try to write clear, maintainable code,
> > and we continue to improve names and code structure to aid
> > understanding. When tricky "rocket science" code is truly needed to
> > solve some problem, we try to keep it bottled up behind clean
> > interfaces.
> >
> >
> > Non-Goals
> >
> > WebKit is an engine, not a browser. We do not plan to develop or
> > host a full-featured web browser based on WebKit. Others are welcome
> > to do so, of course.
> >
> > WebKit is an engineering project not a science project. For new
> > features to be adopted into WebKit, we strongly prefer for the
> > technology or at least the use case for it to be proven.
> >
> > WebKit is not a bundle of maximally general and reusable code - we
> > build some general-purpose parts, but only to the degree needed to
> > be a good web content engine.
> >
> > WebKit is not the solution to every problem. We focus on web
> > content, not complete solutions to every imaginable technology need.
> >
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>