In short, the following tasks (essentially sub-projects) are part of the project. I suggest that each task will get a 'sub-project leader' assigned.
I put the tasks in what I think would be the most likely order in which implementation of these tasks will commence:
Determine and remove deprecated code and unused functionality and classes. Includes making an inventarisation of all classes and their functions. Split classes in 'core' fucntionality and 'application' functionality
Determine how to deal with modules, and implement any necessary changes.
Move duplicate code to methods in parent classes for easier maintenance.
This project also specifically includes the removal of SQL queries from the code.
Note:This project starts 'first', mainly so that other projects don't have to spend time dealing with code that is to be removed. Note that actual removing deprecated code is less time-critical than determining what code is deprecated and what code is 'core' functionality.
Add API documentation (we might make a few statements on what constitutes 'good' documentation )
Make code conformant to the code conventions (and resolve some ambiguities, such as the use of tabs)
Remove any lingering VPRO-specific code.
Makes variables that influence behavior configurable.
Fix the 'language' problem: everything has to be (by default) in english, but ideally configurable to another language. This may mean a few changes to configuration files to make this possible.
The (default) 'us' language should be replaced with the 'en' language.
This does not answer the question on how to store multilangual objects - the focus is on core data and data retrieved from configuration files.
Restrict scoping of class member variables (currently, a lot of variables are public, where they need to be protected, package, or private).
Remove dependencies of code that is unfitting. I.e. remove dependencies of MMObjectBuilder from SCAN related classes, and make it possible to start and stop builders by changing how they are instantiated.
Determine how to handle conversion from old configuration files (if needed), and suggestions on how to alter 'local' classes.
This may overlap with the Apps 2.0 project, which has similar issues.
This focuses on a new package structure.
Most of the work is in proposing a new, more sensible, package structur, and determining what classes belong where. this may also include moving classes out of packages where they have tarditionally belonged, to a package that befits them better (i.e. FieldDefs).
It also proposes new names for classes that do not follow the convention or that have 'bad' names (i.e. the 'CVSReader' class should be named 'CsvReader').
While discussion of the structure should start as soon a spossible, actual implementation will probably start much later - it is vital that the new structure is flexible and makes sense. Due to the large diversity, we'll probably have a lot of flying at each other's throats before we have a structure that satisfies.
In the end the discussions hould be worth it. Note that the restructuring involves everybody - the Deprecation project will send a proposal to the MMC, who will decide whether the proposal is viable. If not, the project will need to make a new proposal. If it is, it will then be proposed to the developers, who will have the final vote.
Implementation of the package structure will start onle after the developers have agreed to the new structure.