Atmosphere police

[dandv]

While evaluating various packages for a large project I'm undertaking, I've seen countless examples of abandoned packages and migration gone wrong. As an example,

https://atmospherejs.com/?q=d3

produces 26 packages, of which many are abandoned, no longer work with 0.9+, and have been superseded by forks that do. I've flagged each, and I've contacted the authors asking them to un-migrate them, after hunting for them via arcane Google searches (some have changed GitHub usernames etc.). If you look at my GitHub activity stream, you'll see a ton of issues and PRs like "Please remove package", "Update for Meteor 0.9", or "Please add Atmosphere URL".

I don't exactly enjoy being OCD about this, and I could use some help. The vast majority of users will not bother to flag mrt: packages that have been superseded, but they do clutter up the Atmosphere search results. What can we do about this? Here are two ideas.

1. Mercilessly flag broken packages.

If it doesn't show a README in Atmosphere, it means the author hasn't bothered to add a git URL, or it's an automatically migrated package that needs help. Flag it!

I've carefully flagged packages superseded by newer forks. If some other folks can please go through search results and re-flag them, the threshold for flagging should hopefully be met. Problem is, they can't see my flags.

2. Work directly with library maintainers to provide official integrations.

Here's how to submit a Meteor packaging PR to popular libraries.

I hope other mechanisms can arise. We're bragging about 2500+ packages on Atmosphere, but my guess after ~two weeks of combing Atmosphere is that half of them are broken in one way or another. This is not exactly a source of "trusted packages".

[dandv]

Here are actual stats from this d3 Atmosphere search. They're very similar to previous searches I've done for other packages (DataTables, forms, maps, you name it) - half the results are a serious waste of time.

UPDATE In the meantime some folks have flagged some of these packages, and they show as flagged globally - thank you! We do need more flags - the more popular a package is, the more flags it needs (10% of the number of downloads).

Old forks obsoleted by https://atmospherejs.com/d3js/d3

https://atmospherejs.com/garrilla/d3
https://atmospherejs.com/meteor/d3
https://atmospherejs.com/sergeyt/d3
https://atmospherejs.com/mrt/d3js-package

Old forks obsoleted by https://atmospherejs.com/pfafman/nvd3

https://atmospherejs.com/mrt/nvd3js
https://atmospherejs.com/mrt/nvd3-revised
https://atmospherejs.com/mrt/meteor-nvd3
https://atmospherejs.com/aramk/d3

Old forks obsoleted by https://atmospherejs.com/peernohell/c3

https://atmospherejs.com/kylesuss/c3

Now Futuregrapher

https://atmospherejs.com/mrt/d3graph
https://atmospherejs.com/futurescaper/d3graph2

Now without dash in name

https://atmospherejs.com/kidovate/dagre-d3

Junk

https://atmospherejs.com/test/1j4psd3

---

26 search results for d3, 12 junk.

The star weighing doesn't always help. For example, the most up-to-date d3 wrapper is https://atmospherejs.com/garrilla/d3, has 3 stars, yet it's below "See More". This proves again that not enough users bother to flag broken packages and star working ones.

Is there anything better we can do than wait indefinitely until the community becomes large enough to weed out junk packages (no pun intended)?

How many users do we miss because of the confusing experience they encounter on Atmosphere?

[tmeasday]

Hey @dandv,

Thanks for taking the time to write this up. I think you make a pretty solid point.

First off, I think everyone agrees that there's not much value in these front end wrapper packages that don't really do anything. Exactly what the solution is is a topic for another forum (and a conversation that's progressing right now I think).

---

To address some of the specific issues you have:

1. Star weighting - actually you've uncovered an issue with the scoring here. The problem is that garrilla:3d didn't have proper scores, not that the starring isn't working. Will sort this out ASAP.
2. In terms of not enough users flagging packages -- Of the 24 packages I see for the search, 7 are visibly flagged. So it looks like the system is getting there, slowly. Perhaps you've made efforts to get others to flag these packages though?

---

We're wondering if it might make sense to bless certain active and trusted community members as "moderators" and to make it so their flagging has more weight (perhaps they insta-flag).

Would this make sense to you @dandv ? Or do you think a more democratic solution is better (perhaps simply lowering the required # of flags to trigger the global flagged state is all that's needed)?

[dandv]

Moderators as a solution have worked well for various software development and Q&A communities, and I have no reason to believe it won't work here. I've been performing this voluntarily for the past weeks and am happy to continue to help. As a safety measure, perhaps no moderator on their own should be able to determine the fate of a package, to avoid the situations like those encountered on StackOverflow.

The only problem with lowering the required # of flags that I see is competitive or revenge downvoting, but my sense is that that would be exceedingly rare. Again, requiring a minimum of X downvotes (which should not be published), would be a defense sufficient for the majority of cases.

Finally, making it easier for users who volunteer to retire their packages would be great. Something like a /retire route on the package, presenting the logged in user with a button to remove the package from Atmosphere (unmigrate for now) would enable me and other volunteers to directly paste that link in GitHub tickets asking them whether they're still maintaining a forgotten repo (example).

[raix]

Maybe there could be a consensus about using the version of a package as an indicator for how stable the package is? I normally use very low versions on packages that havent matured or isnt production ready. We have kind of a problem on the cfs team that its a pre-pre-release thing, but folks are using it and "demanding" bugfixes. I guess now we could mark it -alpha.1 etc. but the package system could perhaps use this info too?

The publish activity of a package is to me the most important indicator, its telling me that the maintainer is doing his job/ its not a dead package.

There are cases where a package could be really old and work perfectly - a reason why the maintainer isnt publishing new versions. (rare)

So a small "police corps" keeping maintainers on their toes are ok, but it could also be an automated thing where packages die if they are not published/updated every 6 month. Now this would result in bad numbers for Meteor marketing - on the other hand it would ensure that only maintained packages live.

The thing I personally would like very much is a way for package writers to be able to make a living on creating and maintaining packages. A package that is funded should weight more, since it would be maintained properly with the goal of being production quality. But theres no business model for package writers yet.

Just some thoughts, sorry about interrupting

Kind regards Morten

[hedcet]

i think - this is the first problem to solve in meteorjs packaging system

please keep different versions of a package under a single package name.
In the case of bootstrap there were several packages like bootstrap, bootstrap-3 and so on.

@dandv
http://ww2.meteor.com/spreadjs/linto
i found atlest 81 package contains "bootstrap" in their name

[splendido]

wow, interesting link...
The table seems not updated thought, how can this be used?

[dandv]

@splendido: which table? I've updated the list of d3 packages, striking out those that have been flagged. There are still quite a few left to flag. Come on, community! :)

[splendido]

sorry @dandv I was referring to the table you can see looking at the link posted by @hedcet

I think you're doing a great job here!!!
...but at the same time it cannot be only you! there should be a better way to improve the commitment of the community to keep he package database clean and up to date.

It doesn't make any sense you can find ~80 packages for bootstrap!
I'd say the best way would be creating a Meteor organization called 'bootstrap' and then have packages like:

bootstrap:css-3.3.0
bootstrap:css-3.3.1
bootstrap:less-3.3.0
bootstrap:less-3.3.1
bootstrap:sass-3.3.0
bootstrap:sass-3.3.1
etc..

then the community should be somehow trained to prefer such a 'pattern' when looking for popular packages ported to meteor.
At the same time the organization should accept a number of contributors among its member and keep a github repo where to receive issues and keep packages up to date.

The thing that should also be avoided is to publish 'private' packages which have only slight modifications w.r.t. 'original' ones simply to have them ready to add to your next app.
This is a different problem and it is left to each developer to get more confident with local package development before thinking to publish a package for 'private' use.

Perhaps some more 'teaching' pages on Atmosphere about this kind of behaviors could help a bit more?

[udondan]

bootstrap already is taken as either a username or organization and AFAIK there's no way of finding out who's the owner. A while back I registered the org bootstrap3 (and with an eye on the future as well bootstrap4 and 5... ;-) ) for a canceled project. Unfortunately there currently is no way to delete an org but I'm of course willing to invite everyone who wants to use it for above suggestion.

[dandv]

@udondan: you can ping @estark37 to delete orgs or convert users to orgs. She's helpful :)

I've also reserved a large number of orgs, because someone who was not very nice, had reserved moment but apparently did nothing with it, and the official moment maintainers can't use it now.

[splendido]

this is surely another problem...
'bootstrap' was just an example to propose a pattern ;-)

[splendido]

hey @hedcet, in case 'fontawesome' is an organization, you can go to meteor.com login with your regular username look for the 'organization' 'tab' under your account settings and 'invite' new users based on their meteor developer usernames.

In case 'fontawesome' is only the package name, hence 'linto:fontawesome' you must use the meteor CLI to add another maintainer via meteor admin!

[dandv]

Thanks @splendido for answering that SO question - you should repost there and get the points :) PS @hedcet: might want to pay a bit more attention to the writing!

[splendido]

do you guys think we should try to put some pressure on organization/users (like @dandv is very well doing) also pinging MDG to eventually depose the current owner and give back the 'organization' to the community?
How much would Meteor gain from such a 'rude' operation?
Probably something to be considered?

[dandv]

I've already asked Emily to put me in touch with the moment guy. It would be the nice thing for him to add me and @ichernev to the organization.

On the other hand, sometimes this borders into trademark infringement. Someone has reserved "google", and I happen to be the only Meteor dev who works at Google. We plan to release some Meteor packages but the namespace is taken. Rather than have our legal/trademark people start talking to MDG/Percolate, I'd prefer to contact that user, who hopefully wanted to do something innocent (maybe wrap some Google API).

[dandv]

@hedcet: can you please add me to the fontawesome organization?

All: I've sent a pretty solid PR to Dave to add official Meteor integration to Font Awesome. Check out the PR files - note the font download tests and the visual checks.

[splendido]

@hedcet, IMHO fontawesome:fontawesome is not the better choice since 'fontawesome' is already clearly standing out from the first part.
What about fontawesome:4.2.0, fontawesome:3.2.1, etc?

[dandv]

The actual organization behind fontawesome is fortawesome (see their GitHub). This is why I've published the official integration at https://atmospherejs.com/fortawesome/fontawesome. Please star!

[splendido]

@dandv, just saw it, was writing right now you took a better path...

so: fortawesome:fontawesome-4-2-1-less etc?
Not sure whether the dot is allowed inside names...

[splendido]

ok, perhaps it's clearer to have only the name without the version, actual package version will reveal the version of the original package to which the meteor package is linked.
Possible mistakes in publishing operations could be absorbed by publishing versions named M.m.p_w as explained in the official documentation about writing packages

[dandv]

Hey all, I've updated my guide on creating official Meteor integrations. Good luck, happy to answer questions and reach a large consensus!

[dandv]

@hedcet - nice table with lots of packages!

1. How did you build it? Where is the source of the data?
2. Can you add the description column? That explains why we see 81 results for "Bootstrap", when there are far fewer wrappers.
3. Can you enable sorting? We'll see the most starred/downloaded/etc. packages.
4. ww2.meteor.com looks official, like a secondary MDG server for www.meteor.com. You don't want to impersonate them, do you? :)

[dandv]

Of course I had click on column headers; nothing happened. Just now I tried to right click (a bit counter-intuitive) and managed to sort.

And I know ww2 is a subdomain just like "autocomplete".meteor.com, but it looks official (see http://stackoverflow.com/questions/1692273/why-ww2-sub-domains), as if it was maintained by MDG.

[dandv]

Kind of annoying to see yet another package that does exactly what an established pacakge does, @SachaG's Spin.js wrapper, without giving any credit or mentioning prior art. Please flag https://atmospherejs.com/hckrs/spin. And how's that moderator flagging feature coming @tmeasday ?

[tmeasday]

Yeah definitely @dandv ! We'll prioritize it for next sprint

[dburles]

I don't entirely agree in this case. Who's to say that Sacha's version is the be all and the end all. Flagging this new package and others in a similar case in the long term could end up stifling overall growth and quality of the package ecosystem.

This is one reason why I am not entirely convinced about a moderated approach to atmosphere.

While the package does use spin.js it's not simply a fork.

On 19 Dec 2014, at 6:09 pm, Dan Dascalescu [email protected] wrote:

Kind of annoying to see yet another package that does exactly what an established pacakge does, @SachaG's Spin.js wrapper, without giving any credit or mentioning prior art. Please flag https://atmospherejs.com/hckrs/spin. And how's that moderator flagging feature coming @tmeasday ?

—
Reply to this email directly or view it on GitHub.

[raix]

I'm not sure about flagging either - I would contact the maintainer first to hear if they wanted to deprecate the package in favor of an official version. But we have to respect that some packages add extra features.

That said I dont believe anybody actually enjoys maintaining wrapper packages - Rather have two maintainers on one package than two packages with each one.

[dandv]

The package may very well be better than @SachaG's, but how? The author doesn't even mention the existence of the original package, let alone reasons why a user would choose one or the other.

It's a question of open source ethics. Give attribution, dude.

Note - I had already contacted the author of that package regarding a different wrapper they published, for summernote. I had approached the original summernote devs, submitted a PR, and they accepted it. Went back to @JarnoLeConte with an update - nothing. Yet he did have time to publish another wrapper.

So I haven't mentioned this entire backstory, but as a moderator, I'd watch for a healthy open source contribution attitude, a collaborative ethic, as well as package functionality.

[raix]

@dandv fair enough - We should give always give credit

[JarnoLeConte]

Hi @dandv, I got a few notifications about package management of you, so I will answer these. First of all I'm not really a package maintainer. We developed meteor-spin and meteor-summernote for a local project and I just published the packages because I have learned that it is good to share code. I wasn't even aware of the fact that there was already a spin package out there.

I have looked at the other spin package and see some differences. So maybe I can add a comparison to the readme for example. Also we will try to contact the authors of spinjs to do a PR request. That is what you call it right?

Also I will hide the summernote-package as you suggested. But what in the case we will add significant changes, because we have a plan to fully integrate summernote within the meteor style of programming. Must that always be done in the official package? Because that is not always what everyone likes, I think?

[dburles]

That's a good point @JarnoLeConte often packages will require some work to get them to play nicely with Meteor and there's definitely going to be more than one way to do that. Take google maps for example (I'm still iterating on this API) https://github.com/dburles/meteor-google-maps.

Personally I think the official packages should provide a proper Meteor integration. And if you fork the package and write one, I see no reason why you shouldn't then submit a PR. A lot of packages (such as summernote) require a bunch of work to integrate, it makes no sense for everyone to have to write that code themselves since it's supposed to be a Meteor package after all...

[raix]

I would personally like the raw official packages - then have other packages build additional Meteor specific features on top.

[dburles]

I can see your point @raix but the problem I feel with that is it would then mean the official packages become simply something other packages depend on and not a package you would really wish to add directly to your application. That could be pretty confusing (and especially frustrating to new users).

[JarnoLeConte]

You must call that "raw packages" I suggest.

I can see your point @raix but the problem I feel with that is it would then mean the official packages become simply something other packages depend on and not a package you would really wish to add directly to your application.

That could be pretty confusing and especially frustrating to new users.

—
Reply to this email directly or view it on GitHub.

[splendido]

If anyone takes an already existing library (which if used as is has some problems) and comes out with a true porting written the Meteor way, I think this deserves to be considered the official package for Meteor.

The real point might be, for the maintainer, how to keep this up to date with mainstream updates of the original library, for which he might try to seek some direct collaboration with original maintainers.

Still, there are a number of libraries needing only a package.js file and some more lines into their README to became official Meteor packages.
For this latter kind, I agree the 'official integration' via PRs to original maintainers plus some easy way to get them auto-publishing the Meteor package at every new release, is the right direction to head to.

[raix]

To be honest - a true isomorphic package is pretty hard to use anywhere else but Meteor. So most of these raw / "official" packages are for other meteor packages to depend on. Thats not a bad thing - we need them in there for the constraint solver to work + we dont want eg. two versions of underscore etc. in one app. (of course it would be nice to have immersive official support for Meteor - but thats going to take awhile - most of these guys use a different stack)

That said it we might have to think packages as modules, libraries and ui-components.

[awatson1978]

Add me to the list of people skeptical about a moderation/superuser
approach. I'd rather see a reputation/trust system, with tagging, badges,
and the like. Which could then be used for smarter searches. We've got
part of one already. We just need to add to it.

Before putting in a system that encourages policing (which will result in
bruised egos and driving people away from the meteor community), lets add a
way to flag whether a library has a minimum level of documentation that
conforms to a style guide. Or whether it's javascript or coffeescript.
Npm/bower dependencies. Tracks that it might be associated with.

On Fri, Dec 19, 2014 at 7:36 AM, Morten N.O. Nørgaard Henriksen <
[email protected]> wrote:

To be honest - a true isomorphic package is pretty hard to use anywhere
else but Meteor. So most of these raw / "official" packages are for other
meteor packages to depend on. Thats not a bad thing - we need them in there
for the constraint solver to work + we dont want eg. two versions of
underscore etc. in one app. (of course it would be nice to have immersive
official support for Meteor - but thats going to take awhile - most of
these guys use a different stack)

That said it we might have to think packages as modules, libraries and
ui-components.

—
Reply to this email directly or view it on GitHub
#297 (comment)
.

[SachaG]

I like the idea of badges. We could have badges for "well maintained", "popular", "recently updated", "used by app X" (where app X could be Telescope, Respondly, etc.)…

[dandv]

@JarnoLeConte,

We developed meteor-spin and meteor-summernote for a local project and I just published the packages because I have learned that it is good to share code. I wasn't even aware of the fact that there was already a spin package out there.

When I need a package for Meteor, I always search on Atmosphere first. Makes sense, no, rather than spending a bunch of time reinventing the wheel?

I'm really curious how you could simply not be aware of the existence of SachaG's spin package, because that would be a huge educational failure of the Meteor ecosystem. Maybe meteor.com and the Meteor docs should emphasize even more searching on Atmosphere? Really curious.

But what in the case we will add significant changes, because we have a plan to fully integrate summernote within the meteor style of programming.

Awesome! That's exactly the point of direct integrations. Consider @RubaXa's Sortable. It's a reorderable list package, and I've submitted a PR to the author to add Meteor support. Now we have rubaxa:sortable, which saves the order of the elements in the list to a Collection, and keeps that in sync with the UI, fully reactively.

Must that always be done in the official package?

There are many advantages to doing so, and I recently gave a talk at Devshop SF on this topic. Here are the relevant slides: http://slides.com/dandvd/packaging-3rd-party-libraries-properly#/3

But even if you have to create a new package, you can still submit a PR to do so in the source repo. In the case of Bootstrap, we have twbs:bootstrap, and twbs:bootstrap-noglyph. The latter doesn't include the Glyphicons font, which is useful if you want to use the fortawesome:fontawesome icons instead.

By the way, if you'd like to work on a deeper summernote integration, it would be great to join the MeteorPackaging GitHub org. I've just sent you an invite.

[awatson1978]

What might also help is having a public/private field, or maybe a
'searchable' field. Sometimes it's important to get a package into
Atmosphere to confirm that your build works; that things are modularized
correctly, that it works through the atmosphere publication process, etc.
But the package isn't quite ready for other people to use yet.

On Fri, Dec 19, 2014 at 9:11 AM, Dan Dascalescu [email protected]
wrote:

@JarnoLeConte https://github.com/Jarnoleconte,

We developed meteor-spin and meteor-summernote for a local project and I
just published the packages because I have learned that it is good to share
code. I wasn't even aware of the fact that there was already a spin package
out there.

When I need a package for Meteor, I always search on Atmosphere first.
Makes sense, no, rather than spending a bunch of time reinventing the wheel?

I'm really curious how you could simply not be aware of the existence
of SachaG's spin package, because that would be a huge educational failure
of the Meteor ecosystem. Maybe meteor.com and the Meteor docs should
emphasize even more searching on Atmosphere? Really curious.

But what in the case we will add significant changes, because we have a
plan to fully integrate summernote within the meteor style of programming.

Awesome! That's exactly the point of direct integrations. Consider @RubaXa
https://github.com/rubaxa's Sortable
https://github.com/RubaXa/Sortable/tree/dev. It's a reorderable list
package, and I've submitted a PR to the author to add Meteor support. Now
we have rubaxa:sortable https://atmospherejs.com/rubaxa/sortable, which
save the order of the elements in the list to a Collection, and keeps that
in sync with the UI, fully reactively.

Must that always be done in the official package?

There are many advantages to doing so, and I recently gave a talk at
Devshop SF https://www.youtube.com/watch?v=g-idz8UPtDM on this topic.
Here are the relevant slides:
http://slides.com/dandvd/packaging-3rd-party-libraries-properly#/3

But even if you have to create a new package, you can still submit a PR to
do so in the source repo. In the case of Bootstrap, we have twbs:bootstrap
https://atmospherejs.com/twbs/bootstrap, and twbs:bootstrap-noglyph
https://atmospherejs.com/twbs/bootstrap-noglyph. The latter doesn't
include the Glyphicons font, which is useful if you want to use the
fortawesome:fontawesome https://atmospherejs.com/fortawesome/fontawesome
icons instead.

By the way, if you'd like to work on a deeper summernote integration
https://github.com/MeteorPackaging/summernote/tree/develop/meteor, it
would be great to join the MeteorPackaging GitHub org. I've just sent you
an invite.

—
Reply to this email directly or view it on GitHub
#297 (comment)
.

[tmeasday]

I guess you can use unmigrated as a proxy for "hidden". It's pretty gross but it's all MDG have given us so I guess we don't have any choice. You can always mark "un-unmigrated" later.

[tmeasday]

@SachaG and @awatson1978 - Maybe one of you should open a separate ticket to discuss the tagging / badge system and how it might work?

[tmeasday]

@dandv I'm curious to hear how you think the ideal scenario should play out. To use summernote as an example (I know basically nothing about this package so forgive me if I say something dumb):

As noted there are two kinds of integrations:

1. "Raw" integrations that do the absolute minimum to include the relevant files at the right places and get the symbols available.
2. "Full" integrations with a Meteoric (often isomorphic and/or synchronous) API.

I'm reading what you are saying to be that the "official" version should be a full integration. This seems like a big commitment and to have a large potential for problems.

Suppose summernote are about to release version 2.0 of their API, which completely breaks the Meteor integration. It may take @JarnoLeConte some time (possibly a lot of time!) to get around to updating/fixing the full integration to work with v2.0 of summernote. What do the summernote devs do in the meantime? They aren't going to wait to release their package. Now we are in a bad place.

I can see this kind of problem happening often. I would have thought a raw official package (and ideally a full official package too where the will exists) makes a lot of sense. Perhaps a "raw" badge on Atmosphere or even a naming scheme like summernote-raw (which will persist across various places people find the package).

What are your thoughts?

[dandv]

@tmeasday: now that it's been a while since things got started on the "sane packaging" front, here are my thoughts:

1. There seems to be wide agreement (example) that for identical functionality (close to the "raw" integrations you mention), there should be only one package. The question is, where to commit these integration PRs?
2. On the other hand, fuller-featured integrations may diverge, and separate repositories may be necessary.
3. While some developers have been happy to merge Meteor packaging PRs into their repos, others were questioning it (Bootstrap, d3), or have accepted the idea but haven't acted on it yet (Font Awesome). Others initially accepted the PR, but later wanted to separate all integration code into other repositories, including Meteor's - see Detaching Meteor support from summernote.
4. Original library maintainers haven't been very enthusiastic about running another grunt command to publish to Atmosphere, despite the minimal effort involved. Great work is underway by @splendido to automate the publishing process.

Given 3. and 4. above, my opinion at the moment is that we should,

1. Centralize 3rd party library Meteor integration code under the MeteorPackaging repository. Whether via submodules or forks, the code will be separate from the original 3rd party library's repo.
2. Publicize the Packaging existing libraries guidelines as the how-to, e.g. on Atmosphere.
3. Share the namespaces that I've reserved - feel free to contact me if you'd like to package a 3rd party library and I have the namespace. Just check namespace availability on Atmosphere, e.g. audio
4. Get @splendido's autopublish fully working, so release tags pushed to GitHub for packages integrated with Meteor automatically trigger a meteor publish to Atmosphere.

Of these, 1, 2 and 3 can continue or proceed right now.

[tmeasday]

@dandv Thanks for the summary and thanks for all your hard work on this.

Re your list of actions above:

I think we'd be happy to integrate something like 2. into our documentation on the site. I've opened a ticket to track it.

Re 1. and 4. -- although I think this is the correct thing to do right now, I wonder if a better long-term solution for very simple "raw" wrapper packages for modules that exist in other package systems (such as bower) is better Meteor integration with those systems.

Or to put it another way, is there any point in writing such wrapper packages for npm-only packages? I'd argue not, and things are much simpler because people writing "true" wrappers for those packages can just require the raw npm package and go from there. Wouldn't it be nice if we could do the same for (say) bootstrap via it's bower package?

What are your thoughts on that right now?

[dandv]

I'd agree that automatic simple/raw wrapping would be better. One value-add of the wrappers I've published is tests. For Bootstrap, there's also a convenience call in Meteor.startup that initializes popups and tooltips (a common gotcha with Bootstrap if you forget to do that).

[zol]

We're going to tackle parts of this issue in #306 by initially introducing a basic moderator system aimed at ridding atmosphere of garbage packages.