eZ Community » Forums » Discussions » Taking the Community Project one step...
expandshrink

Sunday 23 October 2011 3:48:45 pm - 19 replies

» Read full blog post

Introduction

Now that the build process has somewhat stabilized, with Community Project builds coming out every month, it is time to advance further.

One area where we want to gather feedback from the community is the extensions that are bundled in the monthly tarballs.

Monday 24 October 2011 12:28:51 pm

Excellent news Gaetano!

This initiative was anticipated for a very long time.

We are very proud that our efforts in developing eZ Tags are recognized. I just want to add few more credits:

Modified on Monday 24 October 2011 12:31:24 pm by Ivo Lukač

Tuesday 25 October 2011 8:35:40 am

Some things that might be worth considering...

1) Wether to put some of the features from an extension candidate, inside eZP itself instead of have it in an extension?

For example if there's an extension with a very useful workflow or datatype it might be better to integrate it into eZP instead of making an extension for it.

 

2) Collision with eZ Market

If some extension is already on the eZ Market, can it also be a candidate for a bundled community extension?

Can a bundled community extension be published on eZMarket and under what conditions?

Who decides about all that?

Tuesday 25 October 2011 10:24:24 am

Some things that might be worth considering...

1) Wether to put some of the features from an extension candidate, inside eZP itself instead of have it in an extension?

For example if there's an extension with a very useful workflow or datatype it might be better to integrate it into eZP instead of making an extension for it.

Hi Marko,

Very valid point. This would happen on a per-extension basis, based on the observation of the activity around the extension. "Sponsoring" an extension by bundling it into eZ Publish Community Project is a good way for the Community Project Board to attest to its quality and usefulness. Doing so shall also bring the extension into a larger light beam, triggering more feedback on it.

Another tool is eZ Roadmap. Some feature-requests deemed valuable are mappable to existing extensions. An example : http://share.ez.no/feature-requests/auto-store-draft-feature  (check the discussion too).

The inevitable point is, in both cases, to make sure the usefulness of a feature is assessed by the Community.

 2) Collision with eZ Market

If some extension is already on the eZ Market, can it also be a candidate for a bundled community extension?

Can a bundled community extension be published on eZMarket and under what conditions?

Who decides about all that?

Unless the said extension, initially made available on eZ Market, is also distributed by its author(s) under a OSI-compatible license, we can not imagine bundling it in eZ Publish Community Project. The other way around is likely to happen if the original author(s) are willing to go this way. Decision belongs to the original author(s), but the Community Project Board, central bridge between eZ and the Community when it comes to development, can encourage the author(s) and eZ Market owners to get in touch, upon positive community feedback or explicit request.

I hope this helps,
Cheers, 

 

Tuesday 25 October 2011 10:37:07 am

Decision belongs to the original author(s), but the Community Project Board, central bridge between eZ and the Community when it comes to development, can encourage the author(s) and eZ Market owners to get in touch, upon positive community feedback or explicit request.

This sound interesting. It would be nice to see the extensions on eZMarket embrace the same business model (community-enterprise) as eZ Publish has.

Tuesday 25 October 2011 11:22:48 am

Regarding the decision about which extension to include a full democratic way (where only community votes) would be nice but could lead problems because community would like to have as much as possible extension in the build. As we need to keep the quality some dedicated group (like the Community Board) would need to pick extension which are good enough. So my suggestion would be:

  1. Community Board (or some other eZ Gurus group) chooses one (or more) extension candidate for the next build. All the quality criteria should be met.
  2. Community votes once per month on which extension(s) will be included in the next and following bundles

The main risk that I see is that those extension could become less active in the future. There are 2 basic choices in that situation:

  • exclude the extension (bad choice IMO)
  • find other developers or eZ crew to pick it up (that is why the quality criteria are important in the beginning)

 

my2c

Tuesday 25 October 2011 12:00:23 pm

I would just add one step at the begining of Ivo's suggestion:

0) Community members can suggest which extensions should be choosen by the Comunity Board

Tuesday 25 October 2011 12:07:07 pm

I would just add one step at the begining of Ivo's suggestion:

0) Community members can suggest which extensions should be choosen by the Comunity Board

+1 happy.gif Emoticon

Tuesday 25 October 2011 7:06:33 pm

Regardless how you decide which extensions to include, there is no package that will make everyone happy. Let's keep the basic install light, only include very basic extensions (like ezoe), and make several bundles of other extension, each for a typical site, e.g. community site, e-commerce site, etc.

Harry

Tuesday 25 October 2011 8:28:37 pm

@Marko

1. whether features are better coded in an extension or in the kernel is imho not only a matter of usefulness, but also of architecture/design. Kernel is all about content and generic hooks, extensions are all about covering specific needs. Of course, different developers will have different opinions on this matter...

2. developers of oss extensions are welcome to put them in the eZ market, but keep in mind that there is a cost involved in doing so: a certification process to go through, the pledge (read: contract) to support the extension for a given amount of time etc... so it's just normal to expect more pay-for extensions in the marketplace than pure oss one

Tuesday 25 October 2011 8:31:58 pm

@Harry there is work going on both on the enterprise and the community sides to make extension management easier (installation/upgrades/desinstallation/dependency checking, the whole thing). The outcome of this work might make bundled extensions totally irrelevant in the end, but it's not gonna happen overnight. Projects you might want to look up on the community side: ezextensionbuilder, ezpublishbuilder, and the weird (but telltale) ezpearserver

Wednesday 26 October 2011 1:13:57 am

What about this idea...?

Add a feature to download "your flavor of eZ Publish". So that a user can check which extensions he wants in the eZP and then it gets the download of eZP in which all this extensions are bundled and enabled.

Modified on Wednesday 26 October 2011 1:14:40 am by Mavko Žmak

Wednesday 26 October 2011 1:51:28 pm

What about this idea...?

Add a feature to download "your flavor of eZ Publish". So that a user can check which extensions he wants in the eZP and then it gets the download of eZP in which all this extensions are bundled and enabled.

I was going to suggest the same thing, the only problem here is that it would require a system to download and activate automatically those extensions (regenerate autoload and clear the cache), specially for the ones that requires sql commands, it is really a far better idea and it requires some standards, maybe a special repo that would requires a simple approval process (we need also to think about updates here). Just check out how WordPress works.

Modified on Wednesday 26 October 2011 1:55:36 pm by Thiago Campos Viana

Wednesday 26 October 2011 4:42:10 pm

@Thiago @Marko I agree, here's my vision:

  • use pear as package format to install extensions. This way we get a standard repository format, package format, and we can install extensions via pear cli
  • have a pear-repo-browser in the admin interface for browsing remote browsers to install extensions from. set up via ini the list of available repos (sounds familiar? blunk.gif Emoticon )
  • set up a web-driven packaging wizrad on projects.ez.no to allow developers who have their extensions there can use it for creating packages; support source code on github too
  • the format for defining custom tables needed by extensions is known: share/db_schema.dba. We need more support for share/db_data.dba and also for easily generating those files from an existing database
  • we need to be able to store more data in extensions that can not currently be packaged: permissions, states, workflows. Evolving current packaging system preferred, maybe taking code form ezxmlinstaller
  • we need to improve the list of things eZ does when activating an extension:
    • if it's a design (or translation) one, clear tpl cache, content cache
    • it there is some db schema / data in there, propose to import it
    • other: ? (clear other caches, reindex data in ezfind, etc...)
    • dependency checking (needs a full-fledged dependency definition language, eg. this one does not work on oracle and needs ezfind 2.2+)

But we're quite far out into off-topic land at this point...

Wednesday 26 October 2011 5:27:35 pm

To develop a nice extension installer would be superb but we would hit the same problem: how to select which extension to include in this repository....

Thursday 27 October 2011 3:20:18 pm

This initiative could be labeled "Extension incubator".

Any combination of extensions will satisfy some and frustrate others. Also, while first and foremost promoting innovation, we will need to provide a minimum level of continuity when bundling the extensions. Insertion of an extension into the bundle is meant to provide visibility to an extension that the eZ Community jointly praised, in turn triggering, hopefully, more innovation around this extension. Removal of an extension from the bundle will also inevitably happen, keeping the bundle size to a reasonable size and discoverability ( ie. making sure that the bundle extensions get a sufficient amount of attention, avoiding potential dilution of interest due to excessive amount ). 

Temporary solution

  1. Community members can suggest which extensions should be chosen by the Community Project Board,
  2. The Community Project Board chooses the candidate extensions for the next build. All the eligibility criteria should be met (ref. "Selection outcomes" below),
  3. Community votes in the month prior to the build on which extension(s) will be included in the next and following bundles,
Eligibility Criteria 
  • Initially proposed by the Community,
  • Usefulness : generic (ie not project-specific), demand-driven or demand-generating,
  • Activity/livelihood of the extension,
  • Quality (respect of Coding Standards, implementation of the basic best practices (document required), documentation )
  • Compatibility with past (-3 builds at least, for instance) and current CP version,
Selection outcomes 
  • "bundled but not enabled by default" 
    When the extension has potential, was acclaimed by the community but does not satisfy at least one of the other selection criteria. It provides exposure to the extension, potentially triggering participation around it and faster maturation. 
  • "bundled and enabled by default" 
    When all of the eligibility criteria are met.
Exit strategies

Removal of an extension from the bundle will inevitably happen. The reasons may vary, though :

  • The extension did not prove any clear usefulness, per the community feedback,
  • The eligibility criteria ceased to be satisfied during the incubation period (TBD),
  • The extension kept satisfying all eligibility criteria, and the objectives were met : provide more visibility, trigger more innovation around the extension, helping it mature. But the incubation time (TBD) is over and room is to be made for other promising ones. The extension could be tagged as "successfully incubated from 2011.10 to 2012.3" for instance. This tag should be reflected on projects.ez.no, meaning it was somewhat blessed by the community. It would be, imho, a good incentive to candidate to eZ Market, provided the OSS alternative would persist, rewarding the author(s) with paid support activities around his/their work. 

Future

(once the extension installation tools will exist)

Most of the temporary solution artifacts would persist, however the amount of extensions to choose from could be increased.

At the end of the installation wizard, a larger selection of extension could be proposed, initially selected following the same process as selected above. This presents the advantage of not forcing a combination, leaving it more open (to the extent of the collection of extensions to pick from, subset which could be larger, the installer tool facilitating the choice). We could imagine a built-in feedback system, so users could easily, from eZ Publish's back-office, provide reviews, directly stored under the extension's project on projects.ez.no.

Open questions

  • Tools/ways to support votes/proposals (idea: integration to projects.ez.no) ?
  • Tools/ways to gather feedback on a per-extension basis (idea: integration to projects.ez.no, based on the existing review system) ?
  • Upgrades of extensionsexclusion of an extension : what criteria ?
  • Requires a release pace for extensions,
  • Extensions for which frequent updates are not required, but still are useful.

Thoughts ?

Cheers !

Modified on Thursday 27 October 2011 3:21:02 pm by Nicolas Pastorino

Wednesday 29 February 2012 4:27:10 pm

Hi Community,

as far as I can remember Kristof Coomans http://share.ez.no/community/profile/8405 presented a nearly ready and very cool eZ extension loader at an eZ barcamp in Norway some years ago, anybody?

 

Greetings, ekke

Thursday 01 March 2012 2:27:24 pm

Quote from Ekkehard Dörre :

Hi Community,

as far as I can remember Kristof Coomans http://share.ez.no/community/profile/8405 presented a nearly ready and very cool eZ extension loader at an eZ barcamp in Norway some years ago, anybody?

Mmm, can't remember that one. Any pointer ? 

Cheers !

Thursday 15 March 2012 3:39:48 am

Yeah well ... (Re: Ekkehard's comment)

While some do remember the idea,
of that day, few seem to remember to share
what was said with regards to our future.

I think I'm not alone when I say ....

I look forward to the next person
who creates and publicly distributes
such a solution for all the community
to leverage towards greater successes.

Till then, I would not hold your breath.
It's a lot of work I'm sure to bring this idea to fruition.
 The past is the past but the future is out there ... ....

Besides we could all always implement our own,
instead of wishing for a different past, couldn't we ... ?
I mean that's what this thread is really all about anyway, right?

It was so long ago. We know, people move on
and well, not everything makes it into public
distribution in the way you might pine for ...

 

Your the future. You. And for the record, *CKRT!?!

//kracker

See the bridge there ....
Can you here what I'm sayin through the drops?
If you did you would not be here and neither would I ...

This post's Theme song(s):
* Sole : D.O.I. (Death of Industry) w Cadalack Ron & LuckyIAM
** Mirror: http://soundcloud.com/soleonedotorg/d-o-i-death-of-industry-w
* Sole : Write or Die ..
** Mirror: http://soundcloud.com/soleonedotorg/write-or-die
* Sole : UCKRT
** Mirror: http://soundcloud.com/soleonedotorg/uckrt
 

They kept it this way, you should not ...... ..

Modified on Thursday 15 March 2012 3:42:54 am by // kracker

Friday 16 March 2012 11:00:25 am

Anyone wishing to contribute to existing projects for building a community repository platform is welcome! My take: ezpearserver

Modified on Friday 16 March 2012 11:01:03 am by Gaetano Giunta

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu