search

eugeneware / debowerify

A browserify transform to enable the easy use of bower components in browserify client javascript projects. This can be used in conjunction with deamdify to require AMD components from bower as well.
493 stars 51 forks source link

debowerify is now an Open Open Source Project #53

Open eugeneware opened 9 years ago

eugeneware commented 9 years ago

Hi everyone,

I've just released debowerify as an Open Open Source Project

This means that:

Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. This project is more like an open wiki than a standard guarded open source project.

See the CONTRIBUTING.md file for more details.

This has been done in order to scale the maintenance of small but popular node.js modules like debowerify and also to put the governance and control of the project into the hands of it's user and greatest stakeholders.

As a result, all past contributors (ie. you've landed a commit into debowerify) have been given contributor (ie. commit access) to this repo.

The includes the following fine people, which are also listed on the README under the contributor list.

debowerify is only possible due to the excellent work of the following contributors:

Eugene Ware@eugeneware
Justin Hileman@bobthecow
Liam Curry@liamcurry
andö@dre1080
Riku Rouvila@rikukissa
Frank Wallis@frankwallis
Frédéric Langlade-Bellone@fredericlb
pjeby@pjeby
Dave Mac@DveMac
Rhys Evans@wheresrhys
Adam Krebs@akre54
Matt Kunze@MattKunze
Francesc Rosas@frosas
Toby Ho@airportyh
Devin Weaver@sukima
Stein Martin Hustad@smh
00Davo@00Davo
Max Nordlund@maxnordlund

I've been personally struggling to stay across the open issues for this project, so as contributors, please feel free to help to triage, review, resolve issues as you see fit :-)

And once again, a huge thanks for all your support and contributions of this project!

bobthecow commented 9 years ago

:+1:

bobthecow commented 9 years ago

Re: rule number 5, it would make it easier if a .jshintrc and/or .jscsrc config were added to the repo and the CI test suite. I wouldn't make 'em too strict, but it would help contributors (or at least me) remember to check their code style :)

eugeneware commented 9 years ago

That's a great idea. Now... how to turn my coding style into a .jshintrc? :-)

bobthecow commented 9 years ago

That's a really good question. Once upon a time I thought it would be a great project to wrap jshint in with a script that toggled each option back and forth and found the combination with the least number of errors, and generated a .jshintrc for you… but alas, I have more ideas than time, so I always end up doing the process manually :P

maxnordlund commented 9 years ago

Hm, I usually use ESlint nowadays. I have found it to be more configurable then JSHint, and you can always write a custom plugin/rules if then don't fit. I did that for a project to enforce naming conventions, e.g. Class$_secretMethod.

bobthecow commented 9 years ago

@maxnordlund yeh, eslint would be good to. whichever :)

eugeneware commented 9 years ago

Hi guys, sorry I haven't had a lot of time to work on this project as of late. Long story - been very ill due to some complications in a gall bladder surgery.

I realised that I'm the only npm publisher for this package, which is not my intention. If you leave your npm username in this issue I'll give you npm publish permissions.

Thanks again for all your contributions!