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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
