You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by Louis Suárez-Potts <lu...@gmail.com> on 2015/02/11 18:48:11 UTC
Roadmap items
I’d like to propose three roadmap items and suggest owners of these.
1. ODF support. Owner: Dennis. Task: What do we need, abstractly and—more usefully?—concretely to support ODF, or at the least, ODT, in a usable (however you judge) manner? From my perspective, usability means being able to open fairly simple documents, edit them within the original styles, then return to sender or otherwise pass them to others. Ambition here is great; but so is usable proof of concept.
The need for ODF may be waning, at least in some circles. But I’d think the situation is just that there are layers upon layers, and desktop usage, complemented by tablets (and the like) able to manipulate ODF/ODT is inevitably going to grow, and not slowly. ODF would be and is preferred by quite a few, if in percentage smaller than MS’s format, simply because governments have policies preferring it, though actions speak louder.
I don’t see galvanising advancements in the format and I think it would be misguided to dump watts of brainpower energy into doing it, at this point. I do see continued demand and need for devices able to manipulate ODF. Same for OpenOffice’s implementation of ODF.
2. Documentation for developers. Owner: Peter (and others?). Task: Outline for documentation explicating goal and architecture briefly, allowing for future additions as needed.
Every time I talk to Peter he allows he must do documentation. I think in part that’s because he alone has the full architecture in mind (his) and also because it would save him and others (like the rest) time to know that architecture before launching into the bog of mistaken intention and incoherent code.
is that true, though? Or: What could be done now to produce outlines for documentation. My experience elsewhere has been that documentation is often written as it is needed, like a map is drawn after land is discovered: to chart the better narrative for others, so that they don’t make your mistakes.
If so, what can the rest of us do to help? "Us" could include students, newbies, moi, and so on.
3. GSoC and also Jan’s discovery, Semester of Code. I want to press ahead on this and see if we can get a grant. There are some students at the University of Toronto who could, conceivably be qualified and interested. I can take this on, or part of it, but am not sure where to focus; I can correspond with Dennis on this?
louis
Re: Roadmap items
Posted by Louis Suárez-Potts <lu...@gmail.com>.
> On 11-02-2015, at 13:02, jan i <ja...@apache.org> wrote:
>
> On 11 February 2015 at 18:48, Louis Suárez-Potts <lu...@gmail.com> wrote:
>
>> I’d like to propose three roadmap items and suggest owners of these.
>>
>> 1. ODF support. Owner: Dennis. Task: What do we need, abstractly and—more
>> usefully?—concretely to support ODF, or at the least, ODT, in a usable
>> (however you judge) manner? From my perspective, usability means being
>> able to open fairly simple documents, edit them within the original styles,
>> then return to sender or otherwise pass them to others. Ambition here is
>> great; but so is usable proof of concept.
>>
>> The need for ODF may be waning, at least in some circles. But I’d think
>> the situation is just that there are layers upon layers, and desktop usage,
>> complemented by tablets (and the like) able to manipulate ODF/ODT is
>> inevitably going to grow, and not slowly. ODF would be and is preferred by
>> quite a few, if in percentage smaller than MS’s format, simply because
>> governments have policies preferring it, though actions speak louder.
>>
>> I don’t see galvanising advancements in the format and I think it would be
>> misguided to dump watts of brainpower energy into doing it, at this point.
>> I do see continued demand and need for devices able to manipulate ODF. Same
>> for OpenOffice’s implementation of ODF.
>>
>> 2. Documentation for developers. Owner: Peter (and others?). Task: Outline
>> for documentation explicating goal and architecture briefly, allowing for
>> future additions as needed.
>>
>> Every time I talk to Peter he allows he must do documentation. I think in
>> part that’s because he alone has the full architecture in mind (his) and
>> also because it would save him and others (like the rest) time to know that
>> architecture before launching into the bog of mistaken intention and
>> incoherent code.
>>
>> is that true, though? Or: What could be done now to produce outlines for
>> documentation. My experience elsewhere has been that documentation is often
>> written as it is needed, like a map is drawn after land is discovered: to
>> chart the better narrative for others, so that they don’t make your
>> mistakes.
>>
>> If so, what can the rest of us do to help? "Us" could include students,
>> newbies, moi, and so on.
>>
>> 3. GSoC and also Jan’s discovery, Semester of Code. I want to press ahead
>> on this and see if we can get a grant. There are some students at the
>> University of Toronto who could, conceivably be qualified and interested. I
>> can take this on, or part of it, but am not sure where to focus; I can
>> correspond with Dennis on this?
>>
> What do you mean "if we can get a grant". Neither GSoC or Vals gives grants
> to the mentors or projects.
To the students. Not to the mentors. "Get a grant" means too if the proposal is accepted. I did not envision the mentors getting vast sums of money for this, though yes for other things, e.g., lessons.
>
> Thanks for the 3 suggestions, I would like to add:
>
> 4) DocFormats API, Owner Peter/Jan. We need to stabilize the interface
> between the library and the outside world
>
> 5) DocFormats internal filter API. Owner Peter. We need to define a API
> which filter developers can use, this might later form a plugin basis.
>
> 6) Interconnect Editor (JS) both local (without WEB server) and remote
> (through WEB server). Owner: Peter/Jan.
>
> 7) Generate documentation needed for our releases (NOTICE; LICENSE files
> etc). Owner ??
>
> rgds
> jan i.
>
>
>>
>> louis
Re: Roadmap items
Posted by jan i <ja...@apache.org>.
On 11 February 2015 at 18:48, Louis Suárez-Potts <lu...@gmail.com> wrote:
> I’d like to propose three roadmap items and suggest owners of these.
>
> 1. ODF support. Owner: Dennis. Task: What do we need, abstractly and—more
> usefully?—concretely to support ODF, or at the least, ODT, in a usable
> (however you judge) manner? From my perspective, usability means being
> able to open fairly simple documents, edit them within the original styles,
> then return to sender or otherwise pass them to others. Ambition here is
> great; but so is usable proof of concept.
>
> The need for ODF may be waning, at least in some circles. But I’d think
> the situation is just that there are layers upon layers, and desktop usage,
> complemented by tablets (and the like) able to manipulate ODF/ODT is
> inevitably going to grow, and not slowly. ODF would be and is preferred by
> quite a few, if in percentage smaller than MS’s format, simply because
> governments have policies preferring it, though actions speak louder.
>
> I don’t see galvanising advancements in the format and I think it would be
> misguided to dump watts of brainpower energy into doing it, at this point.
> I do see continued demand and need for devices able to manipulate ODF. Same
> for OpenOffice’s implementation of ODF.
>
> 2. Documentation for developers. Owner: Peter (and others?). Task: Outline
> for documentation explicating goal and architecture briefly, allowing for
> future additions as needed.
>
> Every time I talk to Peter he allows he must do documentation. I think in
> part that’s because he alone has the full architecture in mind (his) and
> also because it would save him and others (like the rest) time to know that
> architecture before launching into the bog of mistaken intention and
> incoherent code.
>
> is that true, though? Or: What could be done now to produce outlines for
> documentation. My experience elsewhere has been that documentation is often
> written as it is needed, like a map is drawn after land is discovered: to
> chart the better narrative for others, so that they don’t make your
> mistakes.
>
> If so, what can the rest of us do to help? "Us" could include students,
> newbies, moi, and so on.
>
> 3. GSoC and also Jan’s discovery, Semester of Code. I want to press ahead
> on this and see if we can get a grant. There are some students at the
> University of Toronto who could, conceivably be qualified and interested. I
> can take this on, or part of it, but am not sure where to focus; I can
> correspond with Dennis on this?
>
What do you mean "if we can get a grant". Neither GSoC or Vals gives grants
to the mentors or projects.
Thanks for the 3 suggestions, I would like to add:
4) DocFormats API, Owner Peter/Jan. We need to stabilize the interface
between the library and the outside world
5) DocFormats internal filter API. Owner Peter. We need to define a API
which filter developers can use, this might later form a plugin basis.
6) Interconnect Editor (JS) both local (without WEB server) and remote
(through WEB server). Owner: Peter/Jan.
7) Generate documentation needed for our releases (NOTICE; LICENSE files
etc). Owner ??
rgds
jan i.
>
> louis