Roadmap proposal
Dimitris Glezos
GUADEC has been pretty great so far in terms of Transifexism. Quite a
few people who believe it might be a viable solution for GNOME's needs
for an efficient toolchain for translators. Most immediate need for
GNOME is workflow management, which is important for any project of
its type (large, many teams, existing translation community).
I seized the opportunity to discuss with people about our big TODO
list and features we would like to see implemented at some time in the
future. I think it's important to write down some of our
bigger-picture goals, that will allow us to maybe prioritize our
planned features.
## The 10.000m picture ##
Translations right now are hard. I'd like at some point to be able to
say "Translations are easy. Dead-simple easy."
Get your content translated with one click. Developers, content
providers and admins should spend no time *at all* managing
translations: all tools should be in place for translators to work
efficiently and nobody should spend time deadling with translation
management. The workflow should adapt to people, not the opposite.
## How to get there ##
Thinking as big as possible, the ideal architecture would be a common,
central Transifex instance available for any open source project. A
one-stop place to get your software localized. The feedback I receive
is in line with my POV that this can become important for the whole
open source community.
There are certain occasions where a project might want its own Tx
instance, like for example customizations, added features, etc.
Examples might be GNOME, Fedora, OpenSUSE etc. Making it possible for
these deployments to work with the common one should be a goal IMO. As
much interoperation as possible. This could be way deep in the
roadmap.
So, to get a bit more specific, I'd like to get the common instance up
as quickly as possible (existing features, no statistics,
release-early release-often). Get a prototype up in mid-August, beta
in mid-September and public 1.5 months later maybe. I might be a bit
too optimistic, but roadmaps tend to be like that (which justifies
their often modifications).
I've prepared a proposal for a roadmap for it with more or less a new
major release every month until December. Prioritized items are GSoC
stuff, the common Tx instance, and more big projects. Without further
ado, here it is:
<snip>
# Tx roadmap
## 0.3 -- "Get smart" (20 July)
* "Get current -devel into shape for a release, asap"
* i18n
* Genshi
* Form validation
### 0.3.1 "The rock" (25 July)
* Tests for everything
* Any fixes found so far
## 0.4 "As good as it gets" (1 August)
* De-Fedora-ize
* Local stylesheets, icons
* Some stats, maybe charts
## 0.5 -- "Amelie" (1 September)
* New registrations
* OpenID with existing providers (eg. Fedora)
* RSS feeds (simple)
* Basic CLI in mainline
* AJAX
* Consider starting prototyping for GNOME (release: end of September)
## 0.6 -- "Dr. Strangelove" (1 October)
* aka. "Ready for common playground"
* Basic maintainers UIs (add SF project, request for project addition)
* Code refactoring (merge Chris's changes, OO-ize code)
* Admin features (checkout working? etc)
* Notifications (new projects, commits)
### 0.6.1 -- "I am Sam" (3 October)
* Good documentation (how to add my project which is hosted at X?)
### 0.6.2 (7 October)
* Upload of temporary files (GNOME)
## 0.7 -- "Alphaville" (1 November)
* Fine-grained permissions (IMPORTANT)
* Better control to developers, add branches, etc)
* Gitorious integration (skip the need for SSH access)
* Notifications 2.0 : Per-user choices (like moin), follow-up on
file/project checkbox
* Full featureset in CLI
* usability, easy of use study
## 0.8 "Matrix" (1 December)
* Workflow features (hold/release a file) (merge Vertimus workflow features)
* Plugin mechanism
* svn+https support
* ...
## Long-term, Undecided, Foo
* Minimal (custom) or full (pootle?) web-based translation tool
* Load-balancing support
* Statistics
* Submit to multiple branches
</snip>
A few notes:
* Basically a draft/proposal
* As mentioned earlier, it focuses on what we are good at doing first
and then to other features.
* I couldn't figure out a gradual way to add statistics, and also
we've already have a solution for it (DL).
* Basically these are features I myself can work on -- something like
the minimal featureset. Would love to hear about what other features
could be included in these releases!
-d
--
Dimitris Glezos
Jabber ID: gle...@jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
Asgeir Frimannsson
>
> Transifexian salutations from Istanbul.
>
> GUADEC has been pretty great so far in terms of Transifexism. Quite a
> few people who believe it might be a viable solution for GNOME's needs
> for an efficient toolchain for translators. Most immediate need for
> GNOME is workflow management, which is important for any project of
> its type (large, many teams, existing translation community).
>
> I seized the opportunity to discuss with people about our big TODO
> list and features we would like to see implemented at some time in the
> future. I think it's important to write down some of our
> bigger-picture goals, that will allow us to maybe prioritize our
> planned features.
>
> ## The 10.000m picture ##
>
> Translations right now are hard. I'd like at some point to be able to
> say "Translations are easy. Dead-simple easy."
>
> Get your content translated with one click. Developers, content
> providers and admins should spend no time *at all* managing
> translations: all tools should be in place for translators to work
> efficiently and nobody should spend time deadling with translation
> management. The workflow should adapt to people, not the opposite.
May I add: 'Content Providers' shouldn't have to adapt to the
Translation Infrastructure, the infrastructure should be able to adapt
to various content layouts (intltool, docbook, publican, kde, wiki)
through plugins. This is a big show-stopper for the current system,
and will be very critical when going beyond Fedora.
> ## How to get there ##
>
> Thinking as big as possible, the ideal architecture would be a common,
> central Transifex instance available for any open source project. A
> one-stop place to get your software localized. The feedback I receive
> is in line with my POV that this can become important for the whole
> open source community.
>
> There are certain occasions where a project might want its own Tx
> instance, like for example customizations, added features, etc.
> Examples might be GNOME, Fedora, OpenSUSE etc. Making it possible for
> these deployments to work with the common one should be a goal IMO. As
> much interoperation as possible. This could be way deep in the
> roadmap.
>
> So, to get a bit more specific, I'd like to get the common instance up
> as quickly as possible (existing features, no statistics,
> release-early release-often). Get a prototype up in mid-August, beta
> in mid-September and public 1.5 months later maybe. I might be a bit
> too optimistic, but roadmaps tend to be like that (which justifies
> their often modifications).
I'm pondering about the viability of this. A central instance means
enabling commit access to repositories from outside the project? E.g.
for Fedora it has been easy, as both transifex and the VCS lives
within the same domain, however granting commit access to fedorahosted
to a central transifex instance would probably be a no-go zone for
security reasons.
> I've prepared a proposal for a roadmap for it with more or less a new
> major release every month until December. Prioritized items are GSoC
> stuff, the common Tx instance, and more big projects. Without further
> ado, here it is:
>
> <snip>
>
> # Tx roadmap
>
> ## 0.3 -- "Get smart" (20 July)
> * "Get current -devel into shape for a release, asap"
> * i18n
> * Genshi
> * Form validation
Great to see Diego's work being pushed towards a release :)
cheers,
asgeir
Dimitris Glezos
>
> On Fri, Jul 11, 2008 at 1:34 AM, Dimitris Glezos <dimi...@glezos.com> wrote:
>>
>>
>> ## The 10.000m picture ##
>>
>> Translations right now are hard. I'd like at some point to be able to
>> say "Translations are easy. Dead-simple easy."
>>
>> Get your content translated with one click. Developers, content
>> providers and admins should spend no time *at all* managing
>> translations: all tools should be in place for translators to work
>> efficiently and nobody should spend time deadling with translation
>> management. The workflow should adapt to people, not the opposite.
>
> May I add: 'Content Providers' shouldn't have to adapt to the
> Translation Infrastructure, the infrastructure should be able to adapt
> to various content layouts (intltool, docbook, publican, kde, wiki)
> through plugins. This is a big show-stopper for the current system,
> and will be very critical when going beyond Fedora.
Definitely. I think that as part of the "dead-simple" mantra. In the
end, the UIs shouldn't differentiate between different formats,
repository types, etc. Translators don't care, really.
>> ## How to get there ##
>>
>> Thinking as big as possible, the ideal architecture would be a common,
>> central Transifex instance available for any open source project. A
>> one-stop place to get your software localized. The feedback I receive
>> is in line with my POV that this can become important for the whole
>> open source community.
>>
>> There are certain occasions where a project might want its own Tx
>> instance, like for example customizations, added features, etc.
>> Examples might be GNOME, Fedora, OpenSUSE etc. Making it possible for
>> these deployments to work with the common one should be a goal IMO. As
>> much interoperation as possible. This could be way deep in the
>> roadmap.
>>
>
> I'm pondering about the viability of this. A central instance means
> enabling commit access to repositories from outside the project? E.g.
> for Fedora it has been easy, as both transifex and the VCS lives
> within the same domain, however granting commit access to fedorahosted
> to a central transifex instance would probably be a no-go zone for
> security reasons.
Yup, the infrastructure should adapt to the needs of the people and
not the opposite. Some projects might prefer the central instance for
a variety of reasons (more translators, no downstream branding, less
administrative overhead), but some others might want their own
instance.
But in general, thinking in dVCS terms, projects can tell Tx to submit
to a public repo other than the source (eg. on gitorious or github) or
in a different branch, so security is still controlled this way. And
then there could be other nifty features like uploading files in
temporary storage in Tx and accepting contributions from people from
multiple downstream communities. Feedback is pretty positive for a
common place for translating any open source project.
"Sankarshan (সঙ্কর্ষণ)"
> GUADEC has been pretty great so far in terms of Transifexism. Quite a
> few people who believe it might be a viable solution for GNOME's needs
> for an efficient toolchain for translators. Most immediate need for
> GNOME is workflow management, which is important for any project of
> its type (large, many teams, existing translation community).
Good to know about this. I quite like the idea of your roadmap proposal
and in some way it reflects on the need to continue to incorporate
feedback and suggestions from various communities of Use that are
projected to grow around Transifex.
Looking at the 'proposed' (?) roadmap, the one thing I note is that if I
were a part of infrastructure of some project that wishes to evaluate
and incorporate Tx, I'd want to have a good assessment of the following:
+ how far down the line Tx would be including RFEs and related bits and
bobs relevant to my project (if they aren't already there)
: this effectively means that your high level features for every release
have to be sub-broken-down into which components are being met
+ how quickly do you roll-back tested features from your devel branch
into the stable one and push a release through the door
: in short, how robust is your battery of test cases that make the push
from scissorhands -> stable release possible
+ who all are consuming Tx and what features are they pushing in
: point to note here is that 3 big elephants in the room viz. OO.o, OLPC
and Mozilla are moving to Pootle for both file containment and
translated content management. These projects have big communities of
Participation in the sphere Tx seems to attack (besides workflow) and
thus there may not be much feature requests coming in from distributed,
active and overloaded projects like these
+ November seems far away
: for projects for whom November seems far away, how can they latch into
your codepush cycle and make things happen for you faster.
In a nutshell, I'd like to see a task -> feature based release schedule
up on Tx page which can be checked by anyone who wishes to put Tx in
production.
Sorry for the rambling :)
~sankarshan
ps: GSoC would be over fairly soon - what's the gain in terms of
stability for Tx via GSoC ?
Dimitris Glezos
<sankarshan....@gmail.com> wrote:
>
> Dimitris Glezos wrote:
>
>> GUADEC has been pretty great so far in terms of Transifexism. Quite a
>> few people who believe it might be a viable solution for GNOME's needs
>> for an efficient toolchain for translators. Most immediate need for
>> GNOME is workflow management, which is important for any project of
>> its type (large, many teams, existing translation community).
>
> Good to know about this. I quite like the idea of your roadmap proposal and
> in some way it reflects on the need to continue to incorporate feedback and
> suggestions from various communities of Use that are projected to grow
> around Transifex.
>
> Looking at the 'proposed' (?) roadmap, the one thing I note is that if I
> were a part of infrastructure of some project that wishes to evaluate and
> incorporate Tx, I'd want to have a good assessment of the following:
Hmmm. Difficult email to answer to. I think the two beers I just had
and the late time will either make my reply the best one possible or
make it have no sense at all.
> + how far down the line Tx would be including RFEs and related bits and bobs
> relevant to my project (if they aren't already there)
>
> : this effectively means that your high level features for every release
> have to be sub-broken-down into which components are being met
I agree the roadmap item descriptions could be more descriptive, in
terms of what we're aiming at in a release and what use-cases it
covers best. This could help projects planning on adopting Tx decide
which version to 'wait' for.
> + how quickly do you roll-back tested features from your devel branch into
> the stable one and push a release through the door
>
> : in short, how robust is your battery of test cases that make the push from
> scissorhands -> stable release possible
Looking at the roadmap, I think one can expect a major release every
month until December and one or two minor ones in between. Maybe we
should just schedule a minor one two weeks after the release, anyway,
containing backported features from devel. Given that we only have
Fedora deploying Tx for now, I'm not sure if backporting features is
worth it yet.
In addition, the test suite still needs a lot of work for me to feel
very comfortable with it.
> + who all are consuming Tx and what features are they pushing in
>
> : point to note here is that 3 big elephants in the room viz. OO.o, OLPC and
> Mozilla are moving to Pootle for both file containment and translated
> content management. These projects have big communities of Participation in
> the sphere Tx seems to attack (besides workflow) and thus there may not be
> much feature requests coming in from distributed, active and overloaded
> projects like these
Right now "probably interested consumers" include the following:
Fedora, GNOME, transifex.net, OpenSUSE, Mono, Maemo, independent
projects. The biggest pressure I feel is from the latter, who'd like a
centralzed instance (tx.net) as soon as possible (OLPC would like that
too, just like any upstream project not wanting to host its own
instance). I believe that helping out the vast amount of smaller
projects is easier, mainly because of the deployment singularity. In
short, I think any project would be interested in receiving
translations from a generic Tx instance, assuming we have good
workflow and ACL support.
Getting more translation communities to deploy Tx is highly important,
too. We'd like to test Tx on GNOME, in particular, in the next couple
of months. Because of the 6-month release cycle, windows ripe for
testing and deployment can be tight.
> + November seems far away
>
> : for projects for whom November seems far away, how can they latch into
> your codepush cycle and make things happen for you faster.
The roadmap page has tickets attached for every task. In addition,
I've created a set of tickets with the keyword 'easy_task' attached to
them, for anyone wanting to jump in and help out.
From the projects themselves, I think getting together a set of
requirements they have from Tx is the best thing we could have.
Knowing what's important for projects considering to deploy Tx is a
good thing.
> In a nutshell, I'd like to see a task -> feature based release schedule up
> on Tx page which can be checked by anyone who wishes to put Tx in
> production.
Noted. The scheduled bullet points could be turned into pure features.
Will try to do it soonish.
> ps: GSoC would be over fairly soon - what's the gain in terms of stability
> for Tx via GSoC ?
Ah, this is probably a whole blog post just by itself. I think having
the chance to receive so much attention from Christos and Diego has
been a blessing for Tx. They are both excellent hackers and their
contributions are bigger than just the features they're implementing.
Future-proof dependencies, test suites and the whole infrastructure
(Trac, mailing lists, etc) are things that were put in place very
quickly partly because the team suddenly grew a lot and because these
guys kept bugging me until I fixed some other stuff.
Looking at our activity timeline,
it's pretty obvious we're rocking hard, and I think we're pretty much
enjoying every minute of it. :D
Off to bed now.