Potential GUADEC/Akademy a11y BOF? (was Re: Planning for GNOME 3.0)

Hi All:

Tomorrow (Friday) is the deadline for GUADEC/Akademy submissions.  I'm 
curious if there would be interest in setting up a GUADEC BOF around 
accessibility?  My personal goals would be to focus on three main areas:

1) Bonobo/CORBA deprecation, including AT-SPI/D-Bus, magnification, and 
speech

2) Alignment with KDE a11y

3) WebKit a11y

I think we agree these are all important.  But, I'm curious if people 
who will be attending GUADEC/Akademy would be willing to attend and 
participate in such a BOF and if we can get critical mass to make them 
worthwhile.  In addition, if the response is overwhelming, should we 
consider making separate BOFs?

Will

Willie Walker wrote:
> I'm really excited about GNOME 3.0.  There are a lot of great ideas that 
> people have come up with.
> 
> As people work on new GUI designs, I request that people engage the 
> GNOME accessibility team on their designs.  Accessibility is a big 
> selling point for GNOME and I'd really hate to see it take a step back.
> 
> Too often, GUI designers and developers forget about important details 
> such as keyboard access, theming, and support for the AT-SPI.  It's a 
> lot easier to develop for accessibility from the beginning than to 
> retrofit later.  Engaging earlier than later also helps us act more like 
> a team than adversaries.
> 
> For developers local to the Boston area, I'm happy to take a visit to 
> your sight to go over accessibility considerations and to discuss your 
> new UI's with you from an accessibility standpoint.  I promise to focus 
> solely on accessibility considerations and will avoid general armchair 
> HCI quarterbacking.   For those outside the Boston area, we can try to 
> find someone to visit you for a face-to-face and/or we could do 
> conference calls with screenshots or just shared desktops via VNC.
> 
> Thanks!
> 
> Will
> (your friendly GNOME a11y guy)
> 
> On Apr 2, 2009, at 7:17 AM, Vincent Untz wrote:
> 
>> During the first few months of 2008, a few Release Team members
>> discussed here and there about the state of GNOME. This was nothing
>> official, and it could actually have been considered as some friends
>> talking together about things they deeply care about. There were
>> thoughts that GNOME could stay with the 2.x branch for a very long time
>> given our solid development methods, but that it was not the future that
>> our community wants to see happening. Because of lack of excitement.
>> Because of lack of vision. Slowly, a plan started to emerge. It evolved,
>> changed, was trimmed a bit, made more solid. We started discussing with
>> a few more people, got more feedback. And then, at GUADEC, the Release
>> Team proposed an initial plan to the community that would lead the
>> project to GNOME 3.0. Quite some time passed; actually, too much time
>> passed because too many people were busy with other things. But it's
>> never too late to do the right thing, so let's really be serious about
>> GNOME 3.0 now!
>>
>> Let's first diverge a bit and discuss the general impression that GNOME
>> is lacking a vision. If you look closely at our community, it'd be wrong
>> to say that people are lacking a vision; but the project as a whole does
>> indeed have this issue. What we are missing is people blessing one
>> specific vision and making it official, giving goals to the community so
>> we can all work together in the same direction. In the pre-2.x days, the
>> community accepted as a whole one specific vision, and such an explicit
>> blessing wasn't needed. But during the 2.x cycle, with our six months
>> schedules, it appeared that everything (community, development process,
>> etc.) was just working very well, and as the vision got more and more
>> fulfilled, the long-term plans became less important as we focused on
>> polishing our desktop. But we've now reached a point where our next
>> steps should be moving to another level, and those next steps require
>> important decisions. This is part of what the Release Team should do.
>> Please note that Release Team members don't have to be the ones who have
>> the vision; we "just" have to be the voice of the community.
>>
>> (As a sidenote, the roadmap process [1] that we tried to re-establish
>> two years ago was a first attempt to fix this. Unfortunately, it turned
>> out that we were missing the most important side of things: a
>> project-wide roadmap. This is because a collection of individual
>> roadmaps isn't enough to create a project-wide roadmap.)
>>
>> So let's go to the core topic and discuss what the GNOME 3.0 effort
>> should be. We propose the following list of areas to focus our efforts
>> on:
>>
>>  - Revamp our User Experience
>>  - Streamlining of the Platform
>>  - Promotion of GNOME
>>
>> There are also other potential areas that are worth exploring if there
>> is enough interest from the community.
>>
>> From a release management perspective, there are various questions that
>> are raised in the GNOME 3.0 context. We definitely need a plan to
>> organize the development (see below for details on it), but we might
>> also want to take this opportunity to rethink how we ship GNOME: are the
>> module sets still the best way to deliver GNOME? There is no obvious
>> answer to this, but the way we will present GNOME in the future will
>> certainly have an impact on this.
>>
>>
>> Revamp our User Experience
>> ============================
>>
>> When talking with some great people at GUADEC about GNOME 3.0, one
>> concern that came more than once was that it would be an error to do
>> GNOME 3.0 without any big user-visible change. While some of us didn't
>> necessarily agree with this concern, it was still a fairly valid one.
>> But it turns out that if you tell the community that there's something
>> after 2.x, then the community will stop vaguely thinking about future
>> ideas and start working on concrete plans.
>>
>> It seems pretty clear now that there are two important ideas that can
>> have a real positive impact on the user experience:
>>
>>  - GNOME Shell [2]: the shell idea is not just about changing the panel
>>    and the window manager. It's about changing the way you start an
>>    activity and how you switch between two different activities. Or more
>>    generally, how you manage your different activities on the desktop.
>>
>>  - Changing the way we access documents (via a journal, like GNOME
>>    Zeitgeist [3]): having to deal with a filesystem in their daily work
>>    is not what makes users happy -- on the contrary, they generally just
>>    want to access their documents and not to browse their hard disk.
>>    Providing new solutions to this problem (using timelines, tags,
>>    bookmarks, etc.) is something that has been of interest in our
>>    community for a long time, but we never completely jumped in. We
>>    simply should.
>>
>> These two ideas can form the basis of an overhauled GNOME user
>> experience; they are not the only changes that we can and will do, but
>> they definitely are the most advanced projects to help us move forward
>> in terms of user experience. The GNOME Shell and the GNOME Zeitgeist
>> projects are indeed already well underway, with working code and strong
>> development going on for nearly six months. This means the effort is not
>> about starting those projects, but about first completing them so that
>> people can work daily with them, and then polishing them.
>>
>> There's one obvious question related to those potential changes: what
>> will happen to the old way of doing things? For example, will we still
>> make the GNOME Panel available if, for some reason, people are not
>> immediately happy with GNOME Shell? There's no obvious answer to this,
>> and this will have to be discussed. Some of us believe that it would be
>> a good thing to keep providing the old elements for a limited time, to
>> ease the migration. That being said, doing that would obviously take
>> some development resources and slow down work on what should be the
>> future. Not an easy choice, of course. However, it's worth noting that
>> distributors and other community members using GNOME to build enterprise
>> products will most certainly help maintain the GNOME 2.x shell for quite
>> some time, and the project will support that to the greatest reasonable
>> extent.
>>
>>
>> Streamlining of the Platform
>> ============================
>>
>> Since GNOME 2.0 was released in 2002, there have been quite some changes
>> in our developer platform: new APIs have landed and some other APIs have
>> been deprecated. There are even some platform libraries that are now
>> nearly unused. This just creates some confusion and does not make the
>> life of developers easy. Since we want applications to be developed for
>> GNOME, this is an issue that we should fix.
>>
>> Hence, it makes perfect sense to rework our platform and try to clarify
>> it for newcomers. Here are some steps that should be considered:
>>
>>  - move all of the deprecated libraries out of the platform, so people
>>    stop using them in new code;
>>
>>  - create a staging area in the platform for libraries that aim to be in
>>    our platform but do not offer enough guarantees at the moment (like
>>    GStreamer): this will send a clear message on what should be used;
>>
>>  - include new exciting technologies that we're starting to see used in
>>    our desktop. Some obvious examples are 3D effects (with Clutter) and
>>    geolocalization (with GeoClue and libchamplain).
>>
>>  - rework the way we present the platform to also integrate some of the
>>    external dependencies: while, say, D-Bus or Avahi are external
>>    dependencies, they are definitely what we want developers to use. And
>>    it's easy to be more explicit about this.
>>
>>  - move the bindings closer to the platform when we talk about bindings,
>>    to make them even more visible and attract developers from all
>>    languages.
>>
>> The work that has been done on GObject introspection [4] will also
>> deeply change the way GNOME development can be done; we've already
>> started to see how it can be leveraged in GNOME Shell, and the fact that
>> it can bring new popular languages like Javascript to GNOME is a huge
>> benefit.
>>
>> All this has of course an impact on our applications: we will have to
>> port the code away from all deprecated APIs, but also prepare our
>> applications to be ready for forthcoming changes, like GTK+ 3.0. This is
>> luckily a task that we can easily quantify and the progress can be
>> tracked on a simple web page.
>>
>>
>> Promotion of GNOME
>> ==================
>>
>> Our community has historically been strong on the development side, but
>> we have always struggled to promote GNOME. That's because this is
>> certainly no easy task. Our user base has however grown significantly
>> since our project started, and we failed to recruit people that could
>> have helped here. GNOME 3.0 is an opportunity to change this and attract
>> contributors that can help forge the communication around the GNOME
>> project. The promotion of the project is definitely part of what makes a
>> good release, and the Marketing Team can contribute a lot to the success
>> of 3.0.
>>
>> Of course, an obvious goal for the promotion of GNOME in this context
>> would be preparing the 3.0 release and the messaging around this
>> release. After highlighting the changes done specifically for 3.0, one
>> other immediate idea is to simply show the progress the GNOME project
>> has made since GNOME 2.0: GNOME 2.10 could arguably have been named 3.0
>> when compared to 2.0, and the same goes for 2.20. This could serve as a
>> basis for work on explaining why our evolutionary approach in
>> development works well.
>>
>> One common issue that often came up when discussing how to promote GNOME
>> was that promoting the desktop as a whole is difficult. But there's no
>> need to do that. We can instead focus our messaging around the GNOME
>> experience: the basic GNOME experience simply is the GNOME Shell; but
>> users actually do not use just the basic desktop, and they use
>> applications. We've never explained why the applications developed for
>> GNOME are good; we've never really put those applications under the
>> spotlight. For instance, why shouldn't we put on the front page of the
>> GNOME website a clearly labeled message about a good music manager? We
>> wouldn't have to choose between Rhythmbox or Banshee: we can promote
>> both, since both are good in different ways, and both are good examples
>> of the GNOME experience.
>>
>> This leads us to a third item: relaunch our website. While our current
>> website is known for being broken in various different ways from a
>> communication point of view, we've not been able to deliver the new
>> version that would fix things. Fixing the website is a large task, but
>> we should not give up on this: the GNOME website is a core part of the
>> GNOME identity, and we cannot ignore the current issues. This happened
>> because of lack of manpower, but the good news is that there are web
>> developers that are fond of GNOME and just don't know they can help the
>> project.
>>
>> And the fact that web developers can play an important role is also
>> valid for all of our users. As of now, we are not really empowering
>> users to promote GNOME: what should a user do if he wanted to do so? We
>> all know how some viral communication can benefit a project like ours,
>> so the solution is simple: let's give ourselves a chance to make this
>> happen!
>>
>>
>> Other Potential Areas
>> =====================
>>
>> The areas presented above are actually not a big surprise to anybody
>> following the GNOME development and are fairly obvious choices. However
>> there are other candidates that would help make GNOME 3.0 a success.
>> Those potential focus areas simply need people to step up so we can be
>> sure expectations can be met.
>>
>>  - Desktop Testing [5]: with the recent creation of the Desktop Testing
>>    Team, this topic becomes more and more visible. We can innovate
>>    there, and we actually should: we helped show the way in the free
>>    software world when it comes to usability and accessibility, and
>>    there is no reason for us not aiming at a similar experience for
>>    desktop testing.
>>
>>  - Art: a GTK+ Theming API hackfest was held in February, where some
>>    good consensus was reached on how theming should be done in the
>>    future. This gives us a new opportunity for an updated look and feel.
>>    This can happen with the help from artists: if we have artists and
>>    coders working together, with the coders knowing the needs from
>>    artists, then there is no doubt that the result will simply rock.
>>
>>  - People: the telepathy framework has nicely progressed over the last
>>    few years and it's offering great perspectives to integrate instant
>>    messaging, and more generally, interaction with people in other
>>    applications. With some focus, it could contribute to make GNOME a
>>    social desktop where you do not only work on documents, but where you
>>    also really interact with your friends.
>>
>>  - Mobile: the GNOME Mobile platform was first introduced in GNOME 2.24,
>>    and it helped make our presence in the mobile world visible. A lot of
>>    the changes that are planned around the platform are of direct
>>    interest to the Mobile Team.
>>
>>
>> Organizing the Development
>> ==========================
>>
>> We need to define a clear timeline for the development, with a schedule
>> that will let us check that the development is on the right path. The
>> end goal is simple: we want to deliver GNOME 3.0 by the time of 2.30
>> release. This makes sense for various reasons: from a technical
>> perspective, the timing is good for the integration of new technologies
>> or projects (GNOME Shell, for example); from a messaging point of view,
>> the evolution from 2.30 to 3.0 is logical and easy to understand. It's
>> worth pointing out that if you compare GNOME 2.26 with GNOME 2.0, it's
>> actually quite surprising to see that we have still kept a 2.x version
>> numbering while we could be at 3.x, or even 4.x. Making GNOME 2.30 a 3.0
>> version is of course still an ambitious goal, but we can achieve it
>> thanks to what we learnt in the past.
>>
>> The development methods we have adopted during GNOME 2.x are overall
>> good methods and the community has become used to them. For example,
>> contributors understand the reasons behind the freezes we have and try
>> their best to respect those freezes. This is not something that should
>> be changed because we now have an opportunity to try something else; on
>> the contrary, those methods will make our path to 3.0 easier. Some
>> regressions were pointed out during the past few cycles: those should
>> not be ignored and we believe part of the reasons why they happened is
>> that only a subpart of our community was trying to move forward, which
>> created some controversy; having a community-wide focus should limit
>> those controversies, and hence the regressions as felt by the community.
>>
>> The six months cycle is now part of our culture and has an impact on the
>> free software ecosystem, with distributions basing their schedule on our
>> schedule. Trying to change this crucial element of our release
>> management, which works quite well, would certainly not help us in any
>> way. Therefore, we will keep six months-based schedules. But having
>> project-wide and long-term goals require some adaptation. GNOME 2.28
>> will not be an independent release or a destination in itself, but it
>> will be a logical step towards GNOME 2.30, and therefore GNOME 3.0.
>>
>> Of course, we should be prepared to consider the fact that GNOME 2.30
>> might not be good enough for us to call it 3.0. All of our time-based
>> releases are also quality-based releases: if the QA Team feels a release
>> should be delayed, then it will be delayed. In the context of 3.0, this
>> is something that we should be ready to diagnose early on during the
>> 2.29 development cycle and we should not be afraid of keeping GNOME 2.30
>> as 2.30 and waiting for GNOME 2.32 for the 3.0 release, for example.
>> That being said, we want the community to try as hard as possible to
>> make "GNOME 2.30 = GNOME 3.0" a success.
>>
>> On a more general note, overlaying a long-term development cycle (3
>> years for example) with project-wide goals, on top of our six months
>> development schedules is something we want to keep after GNOME 3.0.
>>
>>
>> Conclusion
>> ==========
>>
>> You can already check out the schedule for the 2.27 and 2.29 development
>> cycles [6]: it contains some concrete steps and deadlines that will help
>> keep our work focused to make GNOME 3.0 a reality.
>>
>> As already mentioned, this is an ambitious plan and it will only be
>> realized if everybody comes out and helps. Companies can contribute a
>> lot -- for instance, the GNOME Shell effort is doing great thanks to Red
>> Hat's involvement. But GNOME wouldn't even exist without all of the
>> volunteers who are passionate about the project. It's because this
>> passion is so strong that we can build such a plan!
>>
>> We're getting there. We strongly believe that all this can make a good
>> plan for GNOME. Sure, it's not perfect. And there will be disagreements
>> and issues along the road. But it is the way forward.
>>
>>
>> The GNOME Release Team,
>>
>>
>> [1] http://live.gnome.org/RoadMap/Process
>> [2] http://live.gnome.org/GnomeShell
>> [3] http://live.gnome.org/GnomeZeitgeist
>> [4] http://live.gnome.org/GObjectIntrospection
>> [5] http://live.gnome.org/DesktopTesting
>> [6] http://live.gnome.org/TwoPointTwentyseven
>>
>> -- 
>> Les gens heureux ne sont pas pressés.
>> _______________________________________________
>> desktop-devel-list mailing list
>> [email protected]
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> _______________________________________________
> desktop-devel-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list