You are viewing a plain text version of this content. The canonical link for it is here.
Posted to odf-dev@incubator.apache.org by Dave Fisher <da...@comcast.net> on 2018/09/10 19:42:12 UTC
[DISCUSS] Retirement of ODF Toolkit from the Apache Incubator
Hi -
It seems that the number of developers actively working on the ODF Toolkit has never grown large enough to be sustainable as an Apache Top Level Project. After nearly 7 years in the Incubator it is time for the ODF Toolkit community to move on.
I think retirement would consist of the following steps.
(1) Decide if the project will move elsewhere - perhaps to its own GitHub repository.
(2) Decide what entity or person should take over odftoolkit.org domain name.
Once those are decided then we can do a VOTE.
Regards,
Dave
Re: [DISCUSS] Retirement of ODF Toolkit from the Apache Incubator
Posted by Dave Fisher <da...@comcast.net>.
Hi -
> On Sep 21, 2018, at 9:21 AM, Svante Schubert <sv...@gmail.com> wrote:
>
> Tom,
>
> Do have a pointer to Labs?
> I only found a company:
> https://apache-labs.com/al-pages/1007/Company-Profile.html
> Just curious to know all potential choices.
Apache Labs is at labs.apache.org
>
> BTW I will be attending the LibreOffice conference in Albania next week and
> aim to discuss the potential future of ODF Toolkit at the TDF with some of
> the members.
> This will be just in time for our next incubator report.
I’m definitely OK with that.
Regards,
Dave
>
> All the best,
> Svante
> ᐧ
>
> Am Di., 11. Sep. 2018 um 16:24 Uhr schrieb Tom Barber <to...@spicule.co.uk>:
>
>> Whilst I tend to agree with Dave, it would be a shame to kick the ODF
>> Toolkit out without some thinking. One thought I did have was would it be
>> possible to migrate ODF Toolkit from Incubator to Labs to keep the
>> development going but also lessen the burden on the incubator?
>>
>>
>> On 11 September 2018 at 10:50:04, Svante Schubert (
>> svante.schubert@gmail.com) wrote:
>>
>> Hello Dave, Everyone!
>>
>> A natural place to move this project is TDF (The Document Foundation)
>> <https://www.documentfoundation.org/>.
>> Both LibreOffice and OpenOffice are of course heavy users of the ODF file
>> format and in need of tools and validators.
>> There should be no problem to move to TDF and let them take over the
>> domain.
>>
>> A more interesting question IMO would be, what progress does this project
>> have to make and what costs do we generate to Apache and/or can we lower
>> them?
>>
>> Allow me to draft some viable future for our project:
>> What we can be certain is, that there does not exist any interoperable
>> office document collaboration in the world so far and people are longing
>> for it.
>> Office 365 & Google Docs are closed source and breaking often the
>> structure of business office documents, e.g. EU funding application
>> templates.
>>
>> Therefore, I have created a prototype for the Toolkit enabled for
>> Collaboration
>> <https://github.com/svanteschubert/odftoolkit/tree/odf-changes>, which
>> was sponsored by PrototypeFund
>> <https://prototypefund.de/project/documents-for-democracy/> / German
>> Ministry of Research
>> <https://www.bmbf.de/de/software-sprint-freie-programmierer-unterstuetzen-3512.html>
>> last winter.
>> Why is this important? Because sending office documents by email / Dropbox
>> / etc. for collaboration is as clever as if software developer would zip
>> their source code repositories and sending these via email / Dropbox / etc.
>> The major question you ask your coworkers to be able to merge their
>> changes back is: What have you changed?
>> For this reason, this prototype module is switching the paradigm from the
>> document file format (full state) to an equivalent list of user changes
>> (creating in sum the same full state).
>> This Toolkit prototype on collaboration
>> <https://github.com/svanteschubert/odftoolkit/tree/odf-changes>
>> transforms any OpenDocument Text into an equivalent sequence of user
>> changes (in JSON - see attachments) and in addition, is able to apply any
>> new user change (similar in JSON) to the document by merging the change
>> into it. By doing so, the module is taking away the complexity of knowledge
>> about the ODF documents and is a perfect fit as a back-end when office
>> documents entering the realm of a business domain.
>>
>> Why am I telling you this?
>> As I am confident that we need more than a group of individuals that work
>> on this project in their spare time. We need companies, which consider this
>> toolkit as a backbone of their business case.
>> To make it more obvious to managers (and to the Apache board members) to
>> believe in the importance of this project, I am working on a showcase where
>> we attach an existing open-source web editor as front-end, where we could
>> view and edit ODT documents.
>>
>> For this reason, I have been travelling recently to Warschau and visited
>> CKSource <https://cksource.com/> to investigate if the "Toolkit
>> Collaboration prototype
>> <https://github.com/svanteschubert/odftoolkit/tree/odf-changes>" could be
>> attached to their new flagship CKEdit5 <https://ckeditor.com/ckeditor-5/>
>> based on operations & changes
>> <https://github.com/ckeditor/ckeditor5-engine/tree/master/src/model/operation>
>> .
>> You know, in extreme even a Microsoft Office (MSO) user could collaborate
>> with a user using VI text editor by exchanging user changes. While the MSO
>> user would see and edit the full-featured document, the VI user would only
>> see and edit text and paragraphs (the latter emulated as lines). Still, all
>> VI text & paragraph edits could be merged back into the original document
>> using Operational Transformation (OT)
>> <http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation>.
>> If this works for VI, it will work for CKEdit5 for sure and using a
>> web-based editor embeddable into any web page is far more attractive to the
>> masses than VI - please, no discussions on this assumption ;-)
>>
>> End of the month, on the 26th of September I will be in Tirana (Albania)
>> and give a talk about Interoperable Document Collaboration
>> <https://libocon.org/2018/the-program/sept-26th-wednesday/> and
>> hopefully, I have the front-end running by then.
>> I will keep you informed...
>>
>> In the end, we would like to provide a setup-up using an open office
>> application that allows receiving "pull requests" consisting of changes
>> only from other users.
>> For instance useable when a famous author publishes his book read-only and
>> some readers provide feedback by those "pull requests", allowing the author
>> to merge only the changes, neglecting the risk to loose or receiving
>> compromised information by overtaking the full document.
>> A wonderful obvious business case for lawyers...
>>
>> As you see, there's a ton of good stuff coming or in the queue, with a lot
>> of potential for good press & new developers.
>> From where I stand, it would be a terrible moment to shut down.
>>
>> Sincerely,
>> Svante
>> ᐧ
>>
>> Am Mo., 10. Sep. 2018 um 21:42 Uhr schrieb Dave Fisher <
>> dave2wave@comcast.net>:
>>
>>> Hi -
>>>
>>> It seems that the number of developers actively working on the ODF
>>> Toolkit has never grown large enough to be sustainable as an Apache Top
>>> Level Project. After nearly 7 years in the Incubator it is time for the ODF
>>> Toolkit community to move on.
>>>
>>> I think retirement would consist of the following steps.
>>>
>>> (1) Decide if the project will move elsewhere - perhaps to its own GitHub
>>> repository.
>>> (2) Decide what entity or person should take over odftoolkit.org domain
>>> name.
>>>
>>> Once those are decided then we can do a VOTE.
>>>
>>> Regards,
>>> Dave
>>>
>>
>> Spicule Limited is registered in England & Wales. Company Number:
>> 09954122. Registered office: First Floor, Telecom House, 125-135 Preston
>> Road, Brighton, England, BN1 6AF. VAT No. 251478891.
>>
>>
>> All engagements are subject to Spicule Terms and Conditions of Business.
>> This email and its contents are intended solely for the individual to whom
>> it is addressed and may contain information that is confidential,
>> privileged or otherwise protected from disclosure, distributing or copying.
>> Any views or opinions presented in this email are solely those of the
>> author and do not necessarily represent those of Spicule Limited. The
>> company accepts no liability for any damage caused by any virus transmitted
>> by this email. If you have received this message in error, please notify us
>> immediately by reply email before deleting it from your system. Service of
>> legal notice cannot be effected on Spicule Limited by email.
>>
Re: [DISCUSS] Retirement of ODF Toolkit from the Apache Incubator
Posted by Svante Schubert <sv...@gmail.com>.
Tom,
Do have a pointer to Labs?
I only found a company:
https://apache-labs.com/al-pages/1007/Company-Profile.html
Just curious to know all potential choices.
BTW I will be attending the LibreOffice conference in Albania next week and
aim to discuss the potential future of ODF Toolkit at the TDF with some of
the members.
This will be just in time for our next incubator report.
All the best,
Svante
ᐧ
Am Di., 11. Sep. 2018 um 16:24 Uhr schrieb Tom Barber <to...@spicule.co.uk>:
> Whilst I tend to agree with Dave, it would be a shame to kick the ODF
> Toolkit out without some thinking. One thought I did have was would it be
> possible to migrate ODF Toolkit from Incubator to Labs to keep the
> development going but also lessen the burden on the incubator?
>
>
> On 11 September 2018 at 10:50:04, Svante Schubert (
> svante.schubert@gmail.com) wrote:
>
> Hello Dave, Everyone!
>
> A natural place to move this project is TDF (The Document Foundation)
> <https://www.documentfoundation.org/>.
> Both LibreOffice and OpenOffice are of course heavy users of the ODF file
> format and in need of tools and validators.
> There should be no problem to move to TDF and let them take over the
> domain.
>
> A more interesting question IMO would be, what progress does this project
> have to make and what costs do we generate to Apache and/or can we lower
> them?
>
> Allow me to draft some viable future for our project:
> What we can be certain is, that there does not exist any interoperable
> office document collaboration in the world so far and people are longing
> for it.
> Office 365 & Google Docs are closed source and breaking often the
> structure of business office documents, e.g. EU funding application
> templates.
>
> Therefore, I have created a prototype for the Toolkit enabled for
> Collaboration
> <https://github.com/svanteschubert/odftoolkit/tree/odf-changes>, which
> was sponsored by PrototypeFund
> <https://prototypefund.de/project/documents-for-democracy/> / German
> Ministry of Research
> <https://www.bmbf.de/de/software-sprint-freie-programmierer-unterstuetzen-3512.html>
> last winter.
> Why is this important? Because sending office documents by email / Dropbox
> / etc. for collaboration is as clever as if software developer would zip
> their source code repositories and sending these via email / Dropbox / etc.
> The major question you ask your coworkers to be able to merge their
> changes back is: What have you changed?
> For this reason, this prototype module is switching the paradigm from the
> document file format (full state) to an equivalent list of user changes
> (creating in sum the same full state).
> This Toolkit prototype on collaboration
> <https://github.com/svanteschubert/odftoolkit/tree/odf-changes>
> transforms any OpenDocument Text into an equivalent sequence of user
> changes (in JSON - see attachments) and in addition, is able to apply any
> new user change (similar in JSON) to the document by merging the change
> into it. By doing so, the module is taking away the complexity of knowledge
> about the ODF documents and is a perfect fit as a back-end when office
> documents entering the realm of a business domain.
>
> Why am I telling you this?
> As I am confident that we need more than a group of individuals that work
> on this project in their spare time. We need companies, which consider this
> toolkit as a backbone of their business case.
> To make it more obvious to managers (and to the Apache board members) to
> believe in the importance of this project, I am working on a showcase where
> we attach an existing open-source web editor as front-end, where we could
> view and edit ODT documents.
>
> For this reason, I have been travelling recently to Warschau and visited
> CKSource <https://cksource.com/> to investigate if the "Toolkit
> Collaboration prototype
> <https://github.com/svanteschubert/odftoolkit/tree/odf-changes>" could be
> attached to their new flagship CKEdit5 <https://ckeditor.com/ckeditor-5/>
> based on operations & changes
> <https://github.com/ckeditor/ckeditor5-engine/tree/master/src/model/operation>
> .
> You know, in extreme even a Microsoft Office (MSO) user could collaborate
> with a user using VI text editor by exchanging user changes. While the MSO
> user would see and edit the full-featured document, the VI user would only
> see and edit text and paragraphs (the latter emulated as lines). Still, all
> VI text & paragraph edits could be merged back into the original document
> using Operational Transformation (OT)
> <http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation>.
> If this works for VI, it will work for CKEdit5 for sure and using a
> web-based editor embeddable into any web page is far more attractive to the
> masses than VI - please, no discussions on this assumption ;-)
>
> End of the month, on the 26th of September I will be in Tirana (Albania)
> and give a talk about Interoperable Document Collaboration
> <https://libocon.org/2018/the-program/sept-26th-wednesday/> and
> hopefully, I have the front-end running by then.
> I will keep you informed...
>
> In the end, we would like to provide a setup-up using an open office
> application that allows receiving "pull requests" consisting of changes
> only from other users.
> For instance useable when a famous author publishes his book read-only and
> some readers provide feedback by those "pull requests", allowing the author
> to merge only the changes, neglecting the risk to loose or receiving
> compromised information by overtaking the full document.
> A wonderful obvious business case for lawyers...
>
> As you see, there's a ton of good stuff coming or in the queue, with a lot
> of potential for good press & new developers.
> From where I stand, it would be a terrible moment to shut down.
>
> Sincerely,
> Svante
> ᐧ
>
> Am Mo., 10. Sep. 2018 um 21:42 Uhr schrieb Dave Fisher <
> dave2wave@comcast.net>:
>
>> Hi -
>>
>> It seems that the number of developers actively working on the ODF
>> Toolkit has never grown large enough to be sustainable as an Apache Top
>> Level Project. After nearly 7 years in the Incubator it is time for the ODF
>> Toolkit community to move on.
>>
>> I think retirement would consist of the following steps.
>>
>> (1) Decide if the project will move elsewhere - perhaps to its own GitHub
>> repository.
>> (2) Decide what entity or person should take over odftoolkit.org domain
>> name.
>>
>> Once those are decided then we can do a VOTE.
>>
>> Regards,
>> Dave
>>
>
> Spicule Limited is registered in England & Wales. Company Number:
> 09954122. Registered office: First Floor, Telecom House, 125-135 Preston
> Road, Brighton, England, BN1 6AF. VAT No. 251478891.
>
>
> All engagements are subject to Spicule Terms and Conditions of Business.
> This email and its contents are intended solely for the individual to whom
> it is addressed and may contain information that is confidential,
> privileged or otherwise protected from disclosure, distributing or copying.
> Any views or opinions presented in this email are solely those of the
> author and do not necessarily represent those of Spicule Limited. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email. If you have received this message in error, please notify us
> immediately by reply email before deleting it from your system. Service of
> legal notice cannot be effected on Spicule Limited by email.
>
Re: [DISCUSS] Retirement of ODF Toolkit from the Apache Incubator
Posted by Tom Barber <to...@spicule.co.uk>.
Whilst I tend to agree with Dave, it would be a shame to kick the ODF
Toolkit out without some thinking. One thought I did have was would it be
possible to migrate ODF Toolkit from Incubator to Labs to keep the
development going but also lessen the burden on the incubator?
On 11 September 2018 at 10:50:04, Svante Schubert (svante.schubert@gmail.com)
wrote:
Hello Dave, Everyone!
A natural place to move this project is TDF (The Document Foundation)
<https://www.documentfoundation.org/>.
Both LibreOffice and OpenOffice are of course heavy users of the ODF file
format and in need of tools and validators.
There should be no problem to move to TDF and let them take over the domain.
A more interesting question IMO would be, what progress does this project
have to make and what costs do we generate to Apache and/or can we lower
them?
Allow me to draft some viable future for our project:
What we can be certain is, that there does not exist any interoperable
office document collaboration in the world so far and people are longing
for it.
Office 365 & Google Docs are closed source and breaking often the structure
of business office documents, e.g. EU funding application templates.
Therefore, I have created a prototype for the Toolkit enabled for
Collaboration
<https://github.com/svanteschubert/odftoolkit/tree/odf-changes>, which was
sponsored by PrototypeFund
<https://prototypefund.de/project/documents-for-democracy/> / German
Ministry of Research
<https://www.bmbf.de/de/software-sprint-freie-programmierer-unterstuetzen-3512.html>
last winter.
Why is this important? Because sending office documents by email / Dropbox
/ etc. for collaboration is as clever as if software developer would zip
their source code repositories and sending these via email / Dropbox / etc.
The major question you ask your coworkers to be able to merge their changes
back is: What have you changed?
For this reason, this prototype module is switching the paradigm from the
document file format (full state) to an equivalent list of user changes
(creating in sum the same full state).
This Toolkit prototype on collaboration
<https://github.com/svanteschubert/odftoolkit/tree/odf-changes> transforms
any OpenDocument Text into an equivalent sequence of user changes (in JSON
- see attachments) and in addition, is able to apply any new user change
(similar in JSON) to the document by merging the change into it. By doing
so, the module is taking away the complexity of knowledge about the ODF
documents and is a perfect fit as a back-end when office documents entering
the realm of a business domain.
Why am I telling you this?
As I am confident that we need more than a group of individuals that work
on this project in their spare time. We need companies, which consider this
toolkit as a backbone of their business case.
To make it more obvious to managers (and to the Apache board members) to
believe in the importance of this project, I am working on a showcase where
we attach an existing open-source web editor as front-end, where we could
view and edit ODT documents.
For this reason, I have been travelling recently to Warschau and visited
CKSource <https://cksource.com/> to investigate if the "Toolkit
Collaboration prototype
<https://github.com/svanteschubert/odftoolkit/tree/odf-changes>" could be
attached to their new flagship CKEdit5 <https://ckeditor.com/ckeditor-5/>
based on operations & changes
<https://github.com/ckeditor/ckeditor5-engine/tree/master/src/model/operation>
.
You know, in extreme even a Microsoft Office (MSO) user could collaborate
with a user using VI text editor by exchanging user changes. While the MSO
user would see and edit the full-featured document, the VI user would only
see and edit text and paragraphs (the latter emulated as lines). Still, all
VI text & paragraph edits could be merged back into the original document
using Operational Transformation (OT)
<http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation>.
If this works for VI, it will work for CKEdit5 for sure and using a
web-based editor embeddable into any web page is far more attractive to the
masses than VI - please, no discussions on this assumption ;-)
End of the month, on the 26th of September I will be in Tirana (Albania)
and give a talk about Interoperable Document Collaboration
<https://libocon.org/2018/the-program/sept-26th-wednesday/> and hopefully,
I have the front-end running by then.
I will keep you informed...
In the end, we would like to provide a setup-up using an open office
application that allows receiving "pull requests" consisting of changes
only from other users.
For instance useable when a famous author publishes his book read-only and
some readers provide feedback by those "pull requests", allowing the author
to merge only the changes, neglecting the risk to loose or receiving
compromised information by overtaking the full document.
A wonderful obvious business case for lawyers...
As you see, there's a ton of good stuff coming or in the queue, with a lot
of potential for good press & new developers.
From where I stand, it would be a terrible moment to shut down.
Sincerely,
Svante
ᐧ
Am Mo., 10. Sep. 2018 um 21:42 Uhr schrieb Dave Fisher <
dave2wave@comcast.net>:
> Hi -
>
> It seems that the number of developers actively working on the ODF Toolkit
> has never grown large enough to be sustainable as an Apache Top Level
> Project. After nearly 7 years in the Incubator it is time for the ODF
> Toolkit community to move on.
>
> I think retirement would consist of the following steps.
>
> (1) Decide if the project will move elsewhere - perhaps to its own GitHub
> repository.
> (2) Decide what entity or person should take over odftoolkit.org domain
> name.
>
> Once those are decided then we can do a VOTE.
>
> Regards,
> Dave
>
--
Spicule Limited is registered in England & Wales. Company Number:
09954122. Registered office: First Floor, Telecom House, 125-135 Preston
Road, Brighton, England, BN1 6AF. VAT No. 251478891.
All engagements
are subject to Spicule Terms and Conditions of Business. This email and its
contents are intended solely for the individual to whom it is addressed and
may contain information that is confidential, privileged or otherwise
protected from disclosure, distributing or copying. Any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of Spicule Limited. The company accepts no
liability for any damage caused by any virus transmitted by this email. If
you have received this message in error, please notify us immediately by
reply email before deleting it from your system. Service of legal notice
cannot be effected on Spicule Limited by email.
Re: [DISCUSS] Retirement of ODF Toolkit from the Apache Incubator
Posted by Svante Schubert <sv...@gmail.com>.
Hello Dave, Everyone!
A natural place to move this project is TDF (The Document Foundation)
<https://www.documentfoundation.org/>.
Both LibreOffice and OpenOffice are of course heavy users of the ODF file
format and in need of tools and validators.
There should be no problem to move to TDF and let them take over the domain.
A more interesting question IMO would be, what progress does this project
have to make and what costs do we generate to Apache and/or can we lower
them?
Allow me to draft some viable future for our project:
What we can be certain is, that there does not exist any interoperable
office document collaboration in the world so far and people are longing
for it.
Office 365 & Google Docs are closed source and breaking often the structure
of business office documents, e.g. EU funding application templates.
Therefore, I have created a prototype for the Toolkit enabled for
Collaboration
<https://github.com/svanteschubert/odftoolkit/tree/odf-changes>, which was
sponsored by PrototypeFund
<https://prototypefund.de/project/documents-for-democracy/> / German
Ministry of Research
<https://www.bmbf.de/de/software-sprint-freie-programmierer-unterstuetzen-3512.html>
last winter.
Why is this important? Because sending office documents by email / Dropbox
/ etc. for collaboration is as clever as if software developer would zip
their source code repositories and sending these via email / Dropbox / etc.
The major question you ask your coworkers to be able to merge their changes
back is: What have you changed?
For this reason, this prototype module is switching the paradigm from the
document file format (full state) to an equivalent list of user changes
(creating in sum the same full state).
This Toolkit prototype on collaboration
<https://github.com/svanteschubert/odftoolkit/tree/odf-changes> transforms
any OpenDocument Text into an equivalent sequence of user changes (in JSON
- see attachments) and in addition, is able to apply any new user change
(similar in JSON) to the document by merging the change into it. By doing
so, the module is taking away the complexity of knowledge about the ODF
documents and is a perfect fit as a back-end when office documents entering
the realm of a business domain.
Why am I telling you this?
As I am confident that we need more than a group of individuals that work
on this project in their spare time. We need companies, which consider this
toolkit as a backbone of their business case.
To make it more obvious to managers (and to the Apache board members) to
believe in the importance of this project, I am working on a showcase where
we attach an existing open-source web editor as front-end, where we could
view and edit ODT documents.
For this reason, I have been travelling recently to Warschau and visited
CKSource <https://cksource.com/> to investigate if the "Toolkit
Collaboration prototype
<https://github.com/svanteschubert/odftoolkit/tree/odf-changes>" could be
attached to their new flagship CKEdit5 <https://ckeditor.com/ckeditor-5/>
based on operations & changes
<https://github.com/ckeditor/ckeditor5-engine/tree/master/src/model/operation>
.
You know, in extreme even a Microsoft Office (MSO) user could collaborate
with a user using VI text editor by exchanging user changes. While the MSO
user would see and edit the full-featured document, the VI user would only
see and edit text and paragraphs (the latter emulated as lines). Still, all
VI text & paragraph edits could be merged back into the original document
using Operational Transformation (OT)
<http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation>.
If this works for VI, it will work for CKEdit5 for sure and using a
web-based editor embeddable into any web page is far more attractive to the
masses than VI - please, no discussions on this assumption ;-)
End of the month, on the 26th of September I will be in Tirana (Albania)
and give a talk about Interoperable Document Collaboration
<https://libocon.org/2018/the-program/sept-26th-wednesday/> and hopefully,
I have the front-end running by then.
I will keep you informed...
In the end, we would like to provide a setup-up using an open office
application that allows receiving "pull requests" consisting of changes
only from other users.
For instance useable when a famous author publishes his book read-only and
some readers provide feedback by those "pull requests", allowing the author
to merge only the changes, neglecting the risk to loose or receiving
compromised information by overtaking the full document.
A wonderful obvious business case for lawyers...
As you see, there's a ton of good stuff coming or in the queue, with a lot
of potential for good press & new developers.
From where I stand, it would be a terrible moment to shut down.
Sincerely,
Svante
ᐧ
Am Mo., 10. Sep. 2018 um 21:42 Uhr schrieb Dave Fisher <
dave2wave@comcast.net>:
> Hi -
>
> It seems that the number of developers actively working on the ODF Toolkit
> has never grown large enough to be sustainable as an Apache Top Level
> Project. After nearly 7 years in the Incubator it is time for the ODF
> Toolkit community to move on.
>
> I think retirement would consist of the following steps.
>
> (1) Decide if the project will move elsewhere - perhaps to its own GitHub
> repository.
> (2) Decide what entity or person should take over odftoolkit.org domain
> name.
>
> Once those are decided then we can do a VOTE.
>
> Regards,
> Dave
>