[Discussion] Would we enable volunteers that develop extensions

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[Discussion] Would we enable volunteers that develop extensions

Peter Kovacs-3
I have a question. How much willing are we to support extensions.

I mean we have here a voice recognition questions, there is the
reporting tool or wiki extension.

We already thinking on creating repos for reporting tool or the wiki
extensions.

But how do we deal with those topics on the organisatorical level?

Do we form I do not know how to name them, task force around them? Do
the people who whish to be delevop these functions do this in an outside
project (independant if this is a Apache project or github self
sufficient hosted)


I would opt that we agree on some form to enable volunteer to use the
project infrastructure and provide them with a stronger feeling that
they are part of the project even if they are only working on an
extension of none core features.

This makes it easier to bring the community together. I mean the wording
3rd parties bring a lot of discussion and the need to explain things, to
the table.


I am just wondering what everyone else thinks.

All the best

Peter

--
This is the Way! http://www.apache.org/theapacheway/index.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discussion] Would we enable volunteers that develop extensions

Mechtilde Stehmann-2
Hello Peter,

I try to build the "extensions" which can be used with AOO Base like
reportbuilder and mysql-connector.

I also try to build the pdf-importer.

IMO you nedd the whole build to get them

Regards

Mechtilde

Am 01.02.21 um 07:46 schrieb Peter Kovacs:

> I have a question. How much willing are we to support extensions.
>
> I mean we have here a voice recognition questions, there is the
> reporting tool or wiki extension.
>
> We already thinking on creating repos for reporting tool or the wiki
> extensions.
>
> But how do we deal with those topics on the organisatorical level?
>
> Do we form I do not know how to name them, task force around them? Do
> the people who whish to be delevop these functions do this in an outside
> project (independant if this is a Apache project or github self
> sufficient hosted)
>
>
> I would opt that we agree on some form to enable volunteer to use the
> project infrastructure and provide them with a stronger feeling that
> they are part of the project even if they are only working on an
> extension of none core features.
>
> This makes it easier to bring the community together. I mean the wording
> 3rd parties bring a lot of discussion and the need to explain things, to
> the table.
>
>
> I am just wondering what everyone else thinks.
>
> All the best
>
> Peter
>

--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discussion] Would we enable volunteers that develop extensions

Peter Kovacs-3
Hello Mechtilde,


On 01.02.21 08:20, Mechtilde wrote:
> Hello Peter,
>
> I try to build the "extensions" which can be used with AOO Base like
> reportbuilder and mysql-connector.
>
> I also try to build the pdf-importer.
Thanks for this great effort.
>
> IMO you nedd the whole build to get them

technically that might be true, but my thoughts are independent of this.
The question is purely organizational.

should extensions be part of the Apache OpenOffice project?

If we accept this as a Part of the Apache Project, do we need a "but"?
Like yes it is part of the Project, but it is not a core responsibility
and has its own sub team / volunteers.

We might need then to think about an internal Attic project, which puts
project on unmaintained.

Or do we say: "no we can not organize this within Apache OpenOffice
Project, we need to organize this outside". Do we need then some sort of
umbrella Organization to connect all 3rd parties with the core?

There are consequences to consider, and maybe from this steps result
that we need to look at


All the best

Peter.

>
> Regards
>
> Mechtilde
>
> Am 01.02.21 um 07:46 schrieb Peter Kovacs:
>> I have a question. How much willing are we to support extensions.
>>
>> I mean we have here a voice recognition questions, there is the
>> reporting tool or wiki extension.
>>
>> We already thinking on creating repos for reporting tool or the wiki
>> extensions.
>>
>> But how do we deal with those topics on the organisatorical level?
>>
>> Do we form I do not know how to name them, task force around them? Do
>> the people who whish to be delevop these functions do this in an outside
>> project (independant if this is a Apache project or github self
>> sufficient hosted)
>>
>>
>> I would opt that we agree on some form to enable volunteer to use the
>> project infrastructure and provide them with a stronger feeling that
>> they are part of the project even if they are only working on an
>> extension of none core features.
>>
>> This makes it easier to bring the community together. I mean the wording
>> 3rd parties bring a lot of discussion and the need to explain things, to
>> the table.
>>
>>
>> I am just wondering what everyone else thinks.
>>
>> All the best
>>
>> Peter
>>
--
This is the Way! http://www.apache.org/theapacheway/index.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Discussion] Would we enable volunteers that develop extensions

Jörg Schmidt-2
In reply to this post by Peter Kovacs-3
Hello,

> -----Original Message-----
> From: Peter Kovacs [mailto:[hidden email]]
> Sent: Monday, February 01, 2021 7:47 AM
> To: [hidden email]
> Subject: [Discussion] Would we enable volunteers that develop
> extensions
>
> I have a question. How much willing are we to support extensions.
>
> I mean we have here a voice recognition questions, there is the
> reporting tool or wiki extension.
>
> We already thinking on creating repos for reporting tool or the wiki
> extensions.
>
> But how do we deal with those topics on the organisatorical level?
>
> Do we form I do not know how to name them, task force around them? Do
> the people who whish to be delevop these functions do this in
> an outside
> project (independant if this is a Apache project or github self
> sufficient hosted)
>
>
> I would opt that we agree on some form to enable volunteer to use the
> project infrastructure and provide them with a stronger feeling that
> they are part of the project even if they are only working on an
> extension of none core features.
>
> This makes it easier to bring the community together. I mean
> the wording
> 3rd parties bring a lot of discussion and the need to explain
> things, to
> the table.
>
>
> I am just wondering what everyone else thinks.


I don't see the need for 'organizational support'.

On the other hand, there would be a need for technical improvements:
-to the extension manager itself
-the extension web page
-to the documentation
and probably also the coordination with LO to keep the 'extension mechanism' compatible to AOO and LO. e.g. the problem of different handling of toolsbars has existed for a long time [1].

Important would be also the improvement of the tools for extension programmers, e.g. the improvement of the BASIC IDE, e.g. an integrated development environment for Python, e.g. the thorough revision of https://extensions.openoffice.org/en/project/basicaddonbuilder-extensions-packager.

The latter is/was a personal concern of mine, so I thought about crowdfunding it years ago, but it doesn't seem realistic, because there are too few interested people.


[1]
some info about this, with reference to BasicAddonBuilder, can be found here:
https://wiki.openoffice.org/wiki/Extensions_Packager#BasicAddonBuilder_and_AOO_4.x




greetings,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discussion] Would we enable volunteers that develop extensions

Mechtilde Stehmann-2
In reply to this post by Peter Kovacs-3
hello Peter,

I have one question inline

Am 01.02.21 um 09:11 schrieb Peter Kovacs:

> Hello Mechtilde,
>
>
> On 01.02.21 08:20, Mechtilde wrote:
>> Hello Peter,
>>
>> I try to build the "extensions" which can be used with AOO Base like
>> reportbuilder and mysql-connector.
>>
>> I also try to build the pdf-importer.
> Thanks for this great effort.
>>
>> IMO you nedd the whole build to get them
>
> technically that might be true, but my thoughts are independent of this.
> The question is purely organizational.
>
> should extensions be part of the Apache OpenOffice project?
Is it possible for all extensions. or is it only possible for the
extensions under Alv2 namely which are still part of the core code?

>
> If we accept this as a Part of the Apache Project, do we need a "but"?
> Like yes it is part of the Project, but it is not a core responsibility
> and has its own sub team / volunteers.
>
> We might need then to think about an internal Attic project, which puts
> project on unmaintained.
>
> Or do we say: "no we can not organize this within Apache OpenOffice
> Project, we need to organize this outside". Do we need then some sort of
> umbrella Organization to connect all 3rd parties with the core?
>
> There are consequences to consider, and maybe from this steps result
> that we need to look at
>
>
> All the best
>
> Peter.
>
Regards

--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [Discussion] Would we enable volunteers that develop extensions

Jörg Schmidt-2
Hallo,

> -----Original Message-----
> From: Mechtilde [mailto:[hidden email]]
> Sent: Monday, February 01, 2021 2:12 PM
> To: [hidden email]
> Subject: Re: [Discussion] Would we enable volunteers that
> develop extensions
>
> hello Peter,
>
> I have one question inline
>
> Am 01.02.21 um 09:11 schrieb Peter Kovacs:
> > Hello Mechtilde,
> >
> >
> > On 01.02.21 08:20, Mechtilde wrote:
> >> Hello Peter,
> >>
> >> I try to build the "extensions" which can be used with AOO
> Base like
> >> reportbuilder and mysql-connector.
> >>
> >> I also try to build the pdf-importer.
> > Thanks for this great effort.
> >>
> >> IMO you nedd the whole build to get them
> >
> > technically that might be true, but my thoughts are
> independent of this.
> > The question is purely organizational.
> >
> > should extensions be part of the Apache OpenOffice project?
>
> Is it possible for all extensions. or is it only possible for the
> extensions under Alv2 namely which are still part of the core code?

mmh ... even the German dictionaries that come with the AOO installation package are not under Apache license.
Or is there a dual licensing for that? In the version from the extension page (https://extensions.openoffice.org) it says anyway:

"License: GNU GPL Version 2 or GPL Version 3 or OASIS 0.1".


Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discussion] Would we enable volunteers that develop extensions

Carl Marcum
In reply to this post by Peter Kovacs-3
Hi Peter,

On 2/1/21 1:46 AM, Peter Kovacs wrote:
> I have a question. How much willing are we to support extensions.
I think for extensions like report builder where the code is donated and
it's a high-profile extension it makes sense.
Much more so if we build and bundle during a release.

Freedom to do releases is another issue. If they're AOO sub-projects we
need to do the releases the same way as the Office and that can be
cumbersome for something as small as an extension when they are done
independently and frequently and most members may not have the
toolchains setup.

I ran into this with things like the NetBeans plugin and some other
developer tools.

I think for the same reason ASF wants a minimum number of developers for
a project, a lot of extensions are probably one or two developers and we
could end up with a lot of abandoned code.

>
> I mean we have here a voice recognition questions, there is the
> reporting tool or wiki extension.
>
> We already thinking on creating repos for reporting tool or the wiki
> extensions.
>
> But how do we deal with those topics on the organisatorical level?
>
> Do we form I do not know how to name them, task force around them? Do
> the people who whish to be delevop these functions do this in an
> outside project (independant if this is a Apache project or github
> self sufficient hosted)
>
>
> I would opt that we agree on some form to enable volunteer to use the
> project infrastructure and provide them with a stronger feeling that
> they are part of the project even if they are only working on an
> extension of none core features.

For most extensions I don't think this is necessary when they have
GitHub, Sourceforge, etc.

>
> This makes it easier to bring the community together. I mean the
> wording 3rd parties bring a lot of discussion and the need to explain
> things, to the table.

I think there are things we can do as a project to support a community
which we need to grow.
Some of which like forums and mailing lists we already do.
Extension developers are welcome on the dev@ list.

There is an api@ list for that purpose but I thought it was shut down for lack of traffic and I didn't subscribe anymore but I see there are a few recent posts within the last year and almost no replies to them :(

Jörg had some good points about Extension Manager support and other tools for extensions and you may know I'm working on new extension creation tools as well.  We can also make sure the Developer Guide is up to date and things like that.

>
>
> I am just wondering what everyone else thinks.
>
> All the best
>
> Peter
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discussion] Would we enable volunteers that develop extensions

Steve Lubbs
My concern is related to security. Consider a bad actor who creates an
extension that, for instance, harvests personal  info. It's one thing if
they are listed on a web page. It's a completely different thing if they
are sanctioned by the AOO project by being more tightly associated with the
AOO project, say by being included in the build.

Of course this is true of the project as it stands now. But the increased
exposure of the AOO project and the potential for a black eye bears
discussion.

2 cents.

Steve

On Mon, Feb 1, 2021, 5:06 PM Carl Marcum <[hidden email]> wrote:

> Hi Peter,
>
> On 2/1/21 1:46 AM, Peter Kovacs wrote:
> > I have a question. How much willing are we to support extensions.
> I think for extensions like report builder where the code is donated and
> it's a high-profile extension it makes sense.
> Much more so if we build and bundle during a release.
>
> Freedom to do releases is another issue. If they're AOO sub-projects we
> need to do the releases the same way as the Office and that can be
> cumbersome for something as small as an extension when they are done
> independently and frequently and most members may not have the
> toolchains setup.
>
> I ran into this with things like the NetBeans plugin and some other
> developer tools.
>
> I think for the same reason ASF wants a minimum number of developers for
> a project, a lot of extensions are probably one or two developers and we
> could end up with a lot of abandoned code.
>
> >
> > I mean we have here a voice recognition questions, there is the
> > reporting tool or wiki extension.
> >
> > We already thinking on creating repos for reporting tool or the wiki
> > extensions.
> >
> > But how do we deal with those topics on the organisatorical level?
> >
> > Do we form I do not know how to name them, task force around them? Do
> > the people who whish to be delevop these functions do this in an
> > outside project (independant if this is a Apache project or github
> > self sufficient hosted)
> >
> >
> > I would opt that we agree on some form to enable volunteer to use the
> > project infrastructure and provide them with a stronger feeling that
> > they are part of the project even if they are only working on an
> > extension of none core features.
>
> For most extensions I don't think this is necessary when they have
> GitHub, Sourceforge, etc.
>
> >
> > This makes it easier to bring the community together. I mean the
> > wording 3rd parties bring a lot of discussion and the need to explain
> > things, to the table.
>
> I think there are things we can do as a project to support a community
> which we need to grow.
> Some of which like forums and mailing lists we already do.
> Extension developers are welcome on the dev@ list.
>
> There is an api@ list for that purpose but I thought it was shut down for
> lack of traffic and I didn't subscribe anymore but I see there are a few
> recent posts within the last year and almost no replies to them :(
>
> Jörg had some good points about Extension Manager support and other tools
> for extensions and you may know I'm working on new extension creation tools
> as well.  We can also make sure the Developer Guide is up to date and
> things like that.
>
> >
> >
> > I am just wondering what everyone else thinks.
> >
> > All the best
> >
> > Peter
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Discussion] Would we enable volunteers that develop extensions

Steve Lubbs
In reply to this post by Carl Marcum
Just a thought.

As part of an effort to enable volunteer extension authors would it make
sense to selectively approve extension functionality for inclusion into
AOO on a case by case basis? If it provides a level of new functionality
that is considered important and compelling, say something that is on
the wish list and that no one has the time to pursue? For instance a PDF
importer that was mentioned earlier.

With the author's permission and effort the extension could be ported to
be core code rather than an extension. The author, upon agreeing to
these conditions could be given the right of first refusal to be the
maintainer of the code. There should also be a proviso that the author
will to do the port.

This, or some permutation, could be one way to reward extension authors
for their efforts, provide incentive, and provide new supported
functionality within the constraints of limited resources.

It goes without saying that this would need to be carefully managed and
some way to vet the new code would be needed.

Like I said, just a thought.

Steve

On 2/1/21 5:06 PM, Carl Marcum wrote:

> Hi Peter,
>
> On 2/1/21 1:46 AM, Peter Kovacs wrote:
>> I have a question. How much willing are we to support extensions.
> I think for extensions like report builder where the code is donated
> and it's a high-profile extension it makes sense.
> Much more so if we build and bundle during a release.
>
> Freedom to do releases is another issue. If they're AOO sub-projects
> we need to do the releases the same way as the Office and that can be
> cumbersome for something as small as an extension when they are done
> independently and frequently and most members may not have the
> toolchains setup.
>
> I ran into this with things like the NetBeans plugin and some other
> developer tools.
>
> I think for the same reason ASF wants a minimum number of developers
> for a project, a lot of extensions are probably one or two developers
> and we could end up with a lot of abandoned code.
>
>>
>> I mean we have here a voice recognition questions, there is the
>> reporting tool or wiki extension.
>>
>> We already thinking on creating repos for reporting tool or the wiki
>> extensions.
>>
>> But how do we deal with those topics on the organisatorical level?
>>
>> Do we form I do not know how to name them, task force around them? Do
>> the people who whish to be delevop these functions do this in an
>> outside project (independant if this is a Apache project or github
>> self sufficient hosted)
>>
>>
>> I would opt that we agree on some form to enable volunteer to use the
>> project infrastructure and provide them with a stronger feeling that
>> they are part of the project even if they are only working on an
>> extension of none core features.
>
> For most extensions I don't think this is necessary when they have
> GitHub, Sourceforge, etc.
>
>>
>> This makes it easier to bring the community together. I mean the
>> wording 3rd parties bring a lot of discussion and the need to explain
>> things, to the table.
>
> I think there are things we can do as a project to support a community
> which we need to grow.
> Some of which like forums and mailing lists we already do.
> Extension developers are welcome on the dev@ list.
>
> There is an api@ list for that purpose but I thought it was shut down
> for lack of traffic and I didn't subscribe anymore but I see there are
> a few recent posts within the last year and almost no replies to them :(
>
> Jörg had some good points about Extension Manager support and other
> tools for extensions and you may know I'm working on new extension
> creation tools as well.  We can also make sure the Developer Guide is
> up to date and things like that.
>
>>
>>
>> I am just wondering what everyone else thinks.
>>
>> All the best
>>
>> Peter
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [Discussion] Would we enable volunteers that develop extensions

Keith N. McKenna
On 2/5/2021 3:53 PM, Steve Lubbs wrote:

> Just a thought.
>
> As part of an effort to enable volunteer extension authors would it make
> sense to selectively approve extension functionality for inclusion into
> AOO on a case by case basis? If it provides a level of new functionality
> that is considered important and compelling, say something that is on
> the wish list and that no one has the time to pursue? For instance a PDF
> importer that was mentioned earlier.
>
> With the author's permission and effort the extension could be ported to
> be core code rather than an extension. The author, upon agreeing to
> these conditions could be given the right of first refusal to be the
> maintainer of the code. There should also be a proviso that the author
> will to do the port.
>
> This, or some permutation, could be one way to reward extension authors
> for their efforts, provide incentive, and provide new supported
> functionality within the constraints of limited resources.
>
> It goes without saying that this would need to be carefully managed and
> some way to vet the new code would be needed.
>
> Like I said, just a thought.
>
> Steve
That could be difficult, as right now extensions authors are free to
license there code any way they like. To bring it into the core code of
the product would require it be under the Apache License 2.0 (ALv2), and
could require a signed Individual Contributor License Agreement as well.

Regards
Keith McKenna

>
> On 2/1/21 5:06 PM, Carl Marcum wrote:
>> Hi Peter,
>>
>> On 2/1/21 1:46 AM, Peter Kovacs wrote:
>>> I have a question. How much willing are we to support extensions.
>> I think for extensions like report builder where the code is donated
>> and it's a high-profile extension it makes sense.
>> Much more so if we build and bundle during a release.
>>
>> Freedom to do releases is another issue. If they're AOO sub-projects
>> we need to do the releases the same way as the Office and that can be
>> cumbersome for something as small as an extension when they are done
>> independently and frequently and most members may not have the
>> toolchains setup.
>>
>> I ran into this with things like the NetBeans plugin and some other
>> developer tools.
>>
>> I think for the same reason ASF wants a minimum number of developers
>> for a project, a lot of extensions are probably one or two developers
>> and we could end up with a lot of abandoned code.
>>
>>>
>>> I mean we have here a voice recognition questions, there is the
>>> reporting tool or wiki extension.
>>>
>>> We already thinking on creating repos for reporting tool or the wiki
>>> extensions.
>>>
>>> But how do we deal with those topics on the organisatorical level?
>>>
>>> Do we form I do not know how to name them, task force around them? Do
>>> the people who whish to be delevop these functions do this in an
>>> outside project (independant if this is a Apache project or github
>>> self sufficient hosted)
>>>
>>>
>>> I would opt that we agree on some form to enable volunteer to use the
>>> project infrastructure and provide them with a stronger feeling that
>>> they are part of the project even if they are only working on an
>>> extension of none core features.
>>
>> For most extensions I don't think this is necessary when they have
>> GitHub, Sourceforge, etc.
>>
>>>
>>> This makes it easier to bring the community together. I mean the
>>> wording 3rd parties bring a lot of discussion and the need to explain
>>> things, to the table.
>>
>> I think there are things we can do as a project to support a community
>> which we need to grow.
>> Some of which like forums and mailing lists we already do.
>> Extension developers are welcome on the dev@ list.
>>
>> There is an api@ list for that purpose but I thought it was shut down
>> for lack of traffic and I didn't subscribe anymore but I see there are
>> a few recent posts within the last year and almost no replies to them :(
>>
>> Jörg had some good points about Extension Manager support and other
>> tools for extensions and you may know I'm working on new extension
>> creation tools as well.  We can also make sure the Developer Guide is
>> up to date and things like that.
>>
>>>
>>>
>>> I am just wondering what everyone else thinks.
>>>
>>> All the best
>>>
>>> Peter
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Discussion] Would we enable volunteers that develop extensions

Dylan Pham
In reply to this post by Steve Lubbs
From a legal perspective I think it's best to leave the extensions by
themselves. It's like having a parent company and many subsidiaries. If
something happens, a particular subsidiary can be cut off without too much
damage to the parent company.

From the build/code maintenance perspective, it keeps the main code base
easier to maintain and build. Imagine the thousands more dependencies for
the thousand more extensions that are popular with users.

And the extension authors can do whatever they want with their product. If
another person thinks they have a better idea for a better extension then
both can compete among users, without the perceived endorsement of the main
AOO.

Dylan

On Fri, Feb 5, 2021 at 12:53 PM Steve Lubbs <[hidden email]> wrote:

> Just a thought.
>
> As part of an effort to enable volunteer extension authors would it make
> sense to selectively approve extension functionality for inclusion into
> AOO on a case by case basis? If it provides a level of new functionality
> that is considered important and compelling, say something that is on
> the wish list and that no one has the time to pursue? For instance a PDF
> importer that was mentioned earlier.
>
> With the author's permission and effort the extension could be ported to
> be core code rather than an extension. The author, upon agreeing to
> these conditions could be given the right of first refusal to be the
> maintainer of the code. There should also be a proviso that the author
> will to do the port.
>
> This, or some permutation, could be one way to reward extension authors
> for their efforts, provide incentive, and provide new supported
> functionality within the constraints of limited resources.
>
> It goes without saying that this would need to be carefully managed and
> some way to vet the new code would be needed.
>
> Like I said, just a thought.
>
> Steve
>
> On 2/1/21 5:06 PM, Carl Marcum wrote:
> > Hi Peter,
> >
> > On 2/1/21 1:46 AM, Peter Kovacs wrote:
> >> I have a question. How much willing are we to support extensions.
> > I think for extensions like report builder where the code is donated
> > and it's a high-profile extension it makes sense.
> > Much more so if we build and bundle during a release.
> >
> > Freedom to do releases is another issue. If they're AOO sub-projects
> > we need to do the releases the same way as the Office and that can be
> > cumbersome for something as small as an extension when they are done
> > independently and frequently and most members may not have the
> > toolchains setup.
> >
> > I ran into this with things like the NetBeans plugin and some other
> > developer tools.
> >
> > I think for the same reason ASF wants a minimum number of developers
> > for a project, a lot of extensions are probably one or two developers
> > and we could end up with a lot of abandoned code.
> >
> >>
> >> I mean we have here a voice recognition questions, there is the
> >> reporting tool or wiki extension.
> >>
> >> We already thinking on creating repos for reporting tool or the wiki
> >> extensions.
> >>
> >> But how do we deal with those topics on the organisatorical level?
> >>
> >> Do we form I do not know how to name them, task force around them? Do
> >> the people who whish to be delevop these functions do this in an
> >> outside project (independant if this is a Apache project or github
> >> self sufficient hosted)
> >>
> >>
> >> I would opt that we agree on some form to enable volunteer to use the
> >> project infrastructure and provide them with a stronger feeling that
> >> they are part of the project even if they are only working on an
> >> extension of none core features.
> >
> > For most extensions I don't think this is necessary when they have
> > GitHub, Sourceforge, etc.
> >
> >>
> >> This makes it easier to bring the community together. I mean the
> >> wording 3rd parties bring a lot of discussion and the need to explain
> >> things, to the table.
> >
> > I think there are things we can do as a project to support a community
> > which we need to grow.
> > Some of which like forums and mailing lists we already do.
> > Extension developers are welcome on the dev@ list.
> >
> > There is an api@ list for that purpose but I thought it was shut down
> > for lack of traffic and I didn't subscribe anymore but I see there are
> > a few recent posts within the last year and almost no replies to them :(
> >
> > Jörg had some good points about Extension Manager support and other
> > tools for extensions and you may know I'm working on new extension
> > creation tools as well.  We can also make sure the Developer Guide is
> > up to date and things like that.
> >
> >>
> >>
> >> I am just wondering what everyone else thinks.
> >>
> >> All the best
> >>
> >> Peter
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
Reply | Threaded
Open this post in threaded view
|

RE: [Discussion] Would we enable volunteers that develop extensions

Jörg Schmidt-2
In reply to this post by Steve Lubbs
Hello,

> -----Original Message-----
> From: Steve Lubbs [mailto:[hidden email]]
> Sent: Friday, February 05, 2021 9:54 PM
> To: [hidden email]
> Subject: Re: [Discussion] Would we enable volunteers that
> develop extensions
>
> Just a thought.
>
> As part of an effort to enable volunteer extension authors
> would it make
> sense to selectively approve extension functionality for
> inclusion into
> AOO on a case by case basis? If it provides a level of new
> functionality
> that is considered important and compelling, say something that is on
> the wish list and that no one has the time to pursue? For
> instance a PDF
> importer that was mentioned earlier.

This is an interesting idea, which I had already mentioned myself (elsewhere).
However, there is the experience of the past to consider, so that it is prevented that extensions, objectively as well as from subjective view of users, are regarded as emergency nail.
It should not be allowed (technically) that AOO is delivered with an inflationary high number of _individual_ extensions, but there should be (also in view of the named purpose to transfer extension code later into core code) a kind of main extension as a container for the individual extensions, so that especially in the extension manager only the one main extension is visible.

Of course, this requires some organization, i.e. that the extension programmers adhere to certain technical conditions, but this effort will pay off in the long run.
As an experience value I can refer to the LiMux project (https://de.wikipedia.org/wiki/LiMux), in which I was involved professionally over many years, and was occupied there with the conversion of specialized applications and VBA macros to OOo extensions.
At that time, there were very detailed specifications (size around 50 DIN-A4 pages) for the creation of extensions, which made integration into the overall project and maintenance much easier.

Of course, we should be open to any programming languages within the extensions (there can also be so-called non-code extensions), but again I would like to mention: turning our gaze more towards Python would be quite beneficial, especially for extensions to be ported into the core code later.
A step in this direction might be the development of an integrated Python IDE, parallel to the StarBasic IDE, in AOO.  

(I would like to emphasize that my personal Python knowledge is limited, so the above is not a personal preference, but a strategic consideration).

> With the author's permission and effort the extension could
> be ported to
> be core code rather than an extension. The author, upon agreeing to
> these conditions could be given the right of first refusal to be the
> maintainer of the code. There should also be a proviso that
> the author
> will to do the port.
>
> This, or some permutation, could be one way to reward
> extension authors
> for their efforts, provide incentive,

I think it would also be a motivation to award membership in the PMC according to objective performance and not depending on the subjective opinion of individuals.



greetings,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Discussion] Would we enable volunteers that develop extensions

Steve Lubbs
Hi Jörg

Overall I like your suggestion.

Steve

On 2/6/21 1:50 AM, Jörg Schmidt wrote:

> Hello,
>
>> -----Original Message-----
>> From: Steve Lubbs [mailto:[hidden email]]
>> Sent: Friday, February 05, 2021 9:54 PM
>> To: [hidden email]
>> Subject: Re: [Discussion] Would we enable volunteers that
>> develop extensions
>>
>> Just a thought.
>>
>> As part of an effort to enable volunteer extension authors
>> would it make
>> sense to selectively approve extension functionality for
>> inclusion into
>> AOO on a case by case basis? If it provides a level of new
>> functionality
>> that is considered important and compelling, say something that is on
>> the wish list and that no one has the time to pursue? For
>> instance a PDF
>> importer that was mentioned earlier.
> This is an interesting idea, which I had already mentioned myself (elsewhere).
> However, there is the experience of the past to consider, so that it is prevented that extensions, objectively as well as from subjective view of users, are regarded as emergency nail.
> It should not be allowed (technically) that AOO is delivered with an inflationary high number of _individual_ extensions, but there should be (also in view of the named purpose to transfer extension code later into core code) a kind of main extension as a container for the individual extensions, so that especially in the extension manager only the one main extension is visible.
>
> Of course, this requires some organization, i.e. that the extension programmers adhere to certain technical conditions, but this effort will pay off in the long run.
> As an experience value I can refer to the LiMux project (https://de.wikipedia.org/wiki/LiMux), in which I was involved professionally over many years, and was occupied there with the conversion of specialized applications and VBA macros to OOo extensions.
> At that time, there were very detailed specifications (size around 50 DIN-A4 pages) for the creation of extensions, which made integration into the overall project and maintenance much easier.
>
> Of course, we should be open to any programming languages within the extensions (there can also be so-called non-code extensions), but again I would like to mention: turning our gaze more towards Python would be quite beneficial, especially for extensions to be ported into the core code later.
> A step in this direction might be the development of an integrated Python IDE, parallel to the StarBasic IDE, in AOO.
>
> (I would like to emphasize that my personal Python knowledge is limited, so the above is not a personal preference, but a strategic consideration).
>
>> With the author's permission and effort the extension could
>> be ported to
>> be core code rather than an extension. The author, upon agreeing to
>> these conditions could be given the right of first refusal to be the
>> maintainer of the code. There should also be a proviso that
>> the author
>> will to do the port.
>>
>> This, or some permutation, could be one way to reward
>> extension authors
>> for their efforts, provide incentive,
> I think it would also be a motivation to award membership in the PMC according to objective performance and not depending on the subjective opinion of individuals.
>
>
>
> greetings,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>