Description
Hey
I've been working with my packages lately and this got me thinking I wanna start renaming some of my packages and I thought about using the collection
namespace.
@dandv: Would you mind adding me to the colllection
organization as I saw that you were one of the maintainers of it.
This is what I have in mind for my own packages:
zimme:collection-behaviours
->collection:behaviours
zimme:collection-timestampable
->collection:timestamp
zimme:collection-softremovable
->collection:softremove
My upcoming work for archiving docs would go into collection:archive
.
I would also like to ask a couple of the other guys if they're willing to join my effort and provide their functionality under the collectiton
namespace.
@rclai
lai:collection-extensions
-> collection:extensions
?
Maybe even collection:core
? (this needs more discussion)
@mattb33
matb33:collection-hooks
-> collection:hooks
?
@dburles
dburles:collection-helpers
-> collection:helpers
?
dburles:mongo-collection-instances
-> collection:instances
?
My thoughts around this is that we all try and rely on each others work as much as possible.
I know @dburles already accepted a PR to use lai:collection-extensions
, which is nice.
I've also seen @lai doing some work on making @matb33's matb33:collection-hooks
rely on lai:collection-extensions
.
I myself would rely on his package for collection:behaviours
to have the option to automatically add the behaviours to all the collections instead of just manually attaching the behaviours to specific collections, but I feel it should be a choice. There will be a need for supporting an exception list though.
In my packages for specific behaviours like collection:softremove
I already rely on matb33:collection-hooks
.
We would all be responsible for our own packages under the namespace, but I believe the benefits of us all working more close together are great.
We would make the decision on which "new" packages we would accept into the namespace.
Examples:
- Once i start working on
collection:archive
I wouldn't publish the work under the namespace until a majority of us feels its ok to do so. - If we get requests from package maintainers to join the namespace we would make that decision together.
I also think we could work out of either the MeteorCommunity
or MeteorPackaging
organization on Github.
Another alternative is to use one of MeteorCollection
, MeteorCollections
or MeteorCollective
organization which I've just registered. I will remove the unused organizations once a decision has been made.
Who knows, maybe @aldeed want to join us with his aldeed:collection2
package under the name
collection:validation
or something in that direction.
I feel that we all could benefit from such an endeavour.
What do you guys think? Do you feel it's worth it?