Re: 2.4 Proposed Modules - 2 weeks left

[Janina Sajka <janina rednote net>]

i must confess I'm having a pretty hard time coming to terms with being
characterized as "just a marketing bullet point." Ouch.

But, let me return to the central question: What are the criteria for
inclusion?

How about the license? Is a proprietary license acceptable? In other
words, is open source also "just a marketing bullet point?"

I would submit that policy and underlying philosophy are not tangential.
They speak directly to the core value of the technology.

Of course, this argument isn't new, either. We've seen the same opinions
in every rights struggle. Ultimately, I must confess that we will be
judged more by our actions than by our words.

If there are consequences to submitting proprietary technology for
inclusion--it won't be taken because it's proprietary--nobody will even
consider submitting such a perversity.

If there are no consequences--doesn't matter that you haven't even
considered how you get to accessible because something is better than
nothing--then how can we trust, we for whom this is a basic issue
determining whether or not we participate.

Please recognize that in the particular application in question,
Epiphany, there's a double insult. Indeed, it seems that Epiphany needs
to experience an epiphany. At the very least you should change that
insulting name.


Havoc Pennington writes:
> From: Havoc Pennington <hp redhat com>
> 
> On Tue, May 06, 2003 at 10:27:03AM -0700, Peter Korn wrote: 
> > Or are you suggesting that it means "there are no fundamental barriers to
> > supporting theming, keyboard operability, and the AT-SPI, but we simply
> > haven't gotten around to doing much work there"?  
> 
> That sounds good.
> 
> Or simply: is the big picture of the application correct.
> 
> What matters is that we are moving in the right direction overall.
> If we adopt Mozilla in 2.4, then Epiphany in 2.6, then khtml in 2.8, 
> then some other thing in 3.0, then that's what would be broken.
> We can't be changing everything all the time.
> 
> So one primary decision-making factor needs to be whether the code
> being evaluated is a subset of where we want to end up.
> 
> If Epiphany is a subset of the end goal, then it's just a matter of
> adding work (such as a11y) and then we're at the end goal. If Epiphany
> isn't, then the end goal means dropping Epiphany; so work on Epiphany
> is wasted.
> 
> In including things in GNOME releases, we need to be guiding
> innovation, focusing our energies on the work that needs doing.
> 
> Other than getting the big-picture direction right, I would say that
> we should be guided by: which decision will be an improvement over
> what users currently have?
> 
> 
> So:
>  - is epiphany is the right direction for the foreseeable future
>    (next year or two) - I would say yes, native widgets + gecko
>  - is epiphany a net gain for users - I would say yes, we have no 
>    browser today
> 
> That is how I would evaluate adding modules.
>  
> > I think the real question here is are we prepared to add to the GNOME 2
> > desktop a major application with very important functionality that is
> > substantially inaccessible, and perhaps further without a commited roadmap
> > to becoming substantially (if not necessarily 100%) accessible in a specific
> > and fairly short term timescale?
> 
> My answer to that question is yes.
> 
> If we want committed roadmaps, then we have to pay somebody.
> 
> We are time-based because feature-based means you have to either a)
> pay somebody or b) be prepared to delay indefinitely. As we don't have 
> those options, we are time based.
> 
> You are advocating the "delay indefinitely" option for the browser -
> because the nature of free software is that we cannot know that any
> *specific* feature will happen at any given time, only that *some
> features* will happen. Blocking the browser on a specific feature is
> b), delay indefinitely.
> 
> Delay indefinitely mean users don't get the work that *did* happen.
> 
> > In no way am I suggesting that we shouldn't move technology forward as
> > rapidly as we can.  But we cannot seriously commit to having an accessible
> > desktop if we are prepared to add things - and especially things large and
> > substantial - that are substantially inaccessible.
> 
> We can't commit upstream GNOME to being 100% accessible, because that
> is a feature-based criterion, and we cannot pay people, and we cannot
> delay indefinitely.
> 
> What we can do is be friendly to a11y - we can be sure that *if*
> someone does the work, they can make the code shipped accessible.
> 
> This is exactly how we treat i18n and every other feature.
> 
> Havoc
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina afb net		Phone: (202) 408-8175