RFC: Merging the notion of collections into projects
Dimitris Glezos
Just like a band-aid.
Right now Transifex supports two notions of "projects": The Project as a
"Software project" and the Collections as a "Collection of software projects".
While the latter sounds perfectly separated from the first, questions have
started to surface which require a lot of code duplication and confusion for
our users:
- "How is that the 'Fedora Project' is considered a collection? It says
'project' in its name, darnit.
- How is Transifex not a collection? It has dependencies right?
- Why do collections have releases and projects not? And if there were such a
thing as 'project releases' what would the difference be with 'collection
releases'?
- When I go to /languages/pt_BR/ why do I only see collections there?
- If we had teams, what difference would a 'collection team' have from a
'project team'?
- What does it mean that 'a project belongs to a collection'?
To keep the story short, we plan to do replace the notion of collections with
the existing and more common, intuitive notion of 'project'. Every collection
will be renamed to a respective project: eg. /projects/fedora/.
- The 'releases' feature will be added to projects. Now projects will be able
to mark releases, as usual: /projects/transifex/r/0.7/
- A release will basically be a list of components and some dates (just like
the releases now).
- A project will be able to 'ship' in a release not only components of its
own, but other projects' components too. Fedora can ship 200 components, and
Transifex can ship its own plus its dependencies (whereas 'ship' means
'these components affect the translation status of my release).
- The relationship between collection-project will be *removed*. This can be
inferred by looking in which projects' components were shipped in previous
releases.
- Finally, some projects have requested to be able to 'outsource' their
translation management needs to 'Collection managers' in the future. We'll
do it this way: Project A can choose to 'trust' the community of project B
(all translators of B are also my translators). When a translator is
given access to project A, he'll automatically be granted translator
access to project B. The downstream maintainer of project B will still have
the choice to remove this permission given to the particular user.
I won't bother mentioning how much better our codebase will be and the
cross-benefits which will be given by allowing us to 'code once use in
both'. We already lack a bunch of features between the two, and, if we
don't merge the two, in the future this diversion will only increase.
Now, what we need to hear is whether the above breaks any workflows badly,
eats babies, or causes kitten deaths while reading it.
-d
--
Dimitris Glezos
Transifex: The Multilingual Publishing Revolution
http://www.transifex.net/ -- http://www.indifex.com/