[Tts-project] does the TTS vs a11y split still make sense?

[Samuel Thibault]

Hello,

Sergio Oller, on jeu. 01 févr. 2018 18:15:59 +0100, wrote:
> 2018-01-31 21:49 GMT+01:00 Paul Gevers <[1]elbrus at debian.org>:
> > Wouldn't the TTS packages receive more exposure in the realm of the
> > a11y team

I'm not sure about this.  I mean, it's not necessarily obvious to people
that text-to-speech can be found in accessibility packages.  Making TTS
a separate team is also a way to express that it needs its own set of
maintainers, so the accessibility team can concentrate on purely a11y
stuff.  Put another way, it avoids the reasoning "a11y people handle
these TTS packages".  Sure, there is a lot of overlap in the teams, but
the idea was that perhaps we can drag people into the TTS team for pure
TTS reasons, who may not have been dragged into the a11y team.

> > (e.g. due to the fact that the a11y team is explicitly
> > listed on udd.d.o/dmd/)?

Uh, I didn't even know that it was there.  Did we really drag people
that way? :)

> > AFAIK, the last couple of years the uploads of TTS packages have been
> > done by members of both teams.

Yes, there is a lot of overlap.  That doesn't mean the teams necessarily
have to merge :)

> > *If* the split is still desired, I *guess* it makes sense to migrate
> > festvox-mbrola, flite, eflite, espeak, espeak-ng, speech-tools and svox
> > (and maybe more) to the TTS team, but I highly doubt it is worth the
> > effort.

It would make sense indeed. With cicero, espeakedit, pcaudiolib, svox,
the list would be complete. There's also sonic, but that's really
something for a11y: making the speech so fast is only for speech
listeners :)

I would however not care too much about taking the effort of moving them
all just for the sake of it.  If TTS people feel they'd like to maintain
some of them, then we can just move them.


All that said, in the end for me the question is: did the existence of
the TTS group drag some people into it that would perhaps not joined the
A11Y group?  If yes, I'd say we should keep it.  Otherwise we can merge
indeed.

Samuel