The main difference between what's in -more and plugins that we as
individuals might release elsewhere is the SLA that comes with the code. By
making it official MooTools code, we're saying we'll support it, there won't
be breaking changes, there will be docs, etc. I still have numerous plugins
in Clientcide that don't quite fit this (StickyWin, for example). They
aren't low-level enough. Slideshows, carousels, popup windows, etc. are too
specific in their implementations.

If I look at the -more plugins now, there aren't any that I think should be
dropped (note that the JS Depender implementation is dropped in develop). If
I ask myself what we should consider adding it's stuff like a good Tabs
class (I have one in the Clientcide repo that I'd be open to pulling in, but
I'd also be open to seeing a different one pulled in).

The barrier for adding a -more plugin is that a -more contributor has to
"sponsor" it - i.e. they are saying that they think it should be there and
the rest of the team doesn't veto it.

But the idea, at least to me, is not to try and have *everything* in there,
rather, it's the stuff that *we* actually use in our projects. It's our
collective work with an SLA attached. That's about it.

As for the forge, we already have a notion of "official" plugins; there just
aren't any in there. That'll change when we split -more up into individual
repos. The -more library will still have a builder, it'll just come from
numerous sources.

Aaron

On Sun, Sep 26, 2010 at 9:36 AM, Rolf -nl <[email protected]> wrote:

> Jeez, what a shit-long post I wrote. Reading back I think most is
> already discussed inside the dev team, because the issue must have
> come up before ;)
> I think moving -more finally to Forge with the option to download as a
> bundle/set would be something to consider. The -more page could still
> exist as is (or without some redundant stuff and maybe with some new
> things) but essentially it's an aggregator of Forge stuff.
>
> Forge should also include slapping a "Moo Dev Approved" sticker on
> plugins/addons that are created for -more or never were in -more but
> are created by a Moo dev team member or are supported by (one of) the
> Moo dev team. Approved add ons should follow the code style guide
> (important imo) and the original devs (either with support of more dev
> team members) should support upcoming mootools releases etc.
>
> /end rant #2
>
> On Sep 26, 12:09 pm, Rolf -nl <[email protected]> wrote:
> > I think it depends quite a lot on the type of project you're working
> > on that decides (for you) what kind of things you use. E.g. for an
> > application/cms I see myself using Mask, HtmlTable, Lang, Date, URI
> > (from Oskar's list) and other times I'm using Fx and Position type
> > stuff. So.. you should probably ask 200 people first to make a top 10
> > list before you can really say what can and what can't be dropped
> > imho.
> >
> > It's up to the downloader as well either just clicking "select all"
> > for -core and/or -more that starting working with Moo even if you have
> > stuff you don't use. If it's too many kb's, someone eventually can or
> > will come back and create a new download with only the stuff they need
> > for that particular project. And if they don't, that's fine too, it's
> > not like that is the responsibility of MooTools.
> >
> > My idea of -more is/was that it should provide a set of extras on top
> > of core that could be considered basic necessities to start building
> > regular website of application like stuff instantly. (I think the
> > MooScroller could fit into that category as plenty of people look for
> > something like this "as soon as" they create overflowing divs with a
> > scroller.)
> > If you're looking for extra functionality, other ways of doing it,
> > improved/enhanced versions, etc. you can checkout the Forge (which you
> > should do anyway!). Maybe some Forge plugins could actually be moved
> > into -more over time. E.g. something that has to do with storage or a
> > smart Validator extension, or extras like Loop or simpleDelay, or...
> > hmm this could turn into a problem! ;)
> >
> > You can promote Forge more if you drop -more, move everything to the
> > Forge and create a page where you can click like a set to download.
> > Like "This is what More would have been" and then it would collect all
> > plugins that were previously in -more. These could be marked with some
> > "Original Moo Dev Team plugin" so you kinda know what to expect, which
> > I think is good for newcomers and hell, everyone else too really.
> >
> > As far as promoting the Forge and stuff on it would be a monthly blog
> > post with a list of tested and highlighted plugins. Like David Walsh
> > is doing every now and then, but focussing on Forge and what More Dev
> > Team members consider interesting. These could be really simple string
> > enhancing methods or some Class extension so it wouldn't take too much
> > time, but I fully understand nobody really has time :) Maybe just a
> > month blog post with 10 or less randomly selected added plugins from
> > the last month (if there are more, just add a link to Forge). No
> > review, just the names + short description entered by the uploader to
> > get the word out. Good for newcomers, good for ppl not visiting Forge
> > every week, good for other sites that pick up the blog. An editor
> > could verify if some plugins aren't really suitable to add etc. this
> > is trivial.
> >
> > /end Forge rant
> >
> > Hmm, I think leaving everything as is will be fine until 2012 ;)
> >
> > On Sep 26, 9:54 am, אריה גלזר <[email protected]> wrote:
> >
> >
> >
> > > you can always get statistics from the more builder....
> >
> > > On Sun, Sep 26, 2010 at 2:28 AM, Christoph Pojer
> > > <[email protected]>wrote:
> >
> > > > btw. just saying that the docs do not (just) reflect the usage but
> > > > also the complexity of such plugins. So a more complex plugin might
> > > > get more hits on the docs than a less complex one.
> >
> > > --
> > > Arieh Glazer
> > > אריה גלזר
> > > 052-5348-561
> > > 5561
>

Reply via email to