Collaborators needed for this project

[williamkapke]

Hi all.

I've always hoped this project would be owned by a dynamic set of collaborators and it is certainly time. There are several open issues that I haven't been able to get to... which is terrible. Offline responsibilities come & go... and with it, the response time to issues. The rest of my year is going to continue to be very demanding with other things that need to take priority.

The number of folks that have found this project and given help has really surprised me. It seemed so obscure when I started it and I had to try to figure things out, mostly, on my own. Thank you so much for participating! It's been really great.

To keep things progressing, I'm going to need help. More specifically, I need to hand over control to a group of collaborators. I see the folks over at sealsystems have active development on their fork so- maybe ya'll are interested? /cc @StefanScherer @seal-mis @seal-mt

... but anyone that is interested in helping, please LMK!

All collaborators will get:

• push access here
• publish access to NPM
• freedom to collaborate and take the project in the direction they want.
• I just ask that all changes need an approval from another collaborator before merge/publish

Thanks again, hope someone can help!

[StefanScherer]

@williamkapke Thanks for the reminder :-)
I had some other projects in the last months but our team is getting closer to work on more IPP related projects.
So we will also improve the ipp module if some features we need are missing.
We have discussed your request for collaborators and came to the same idea to help maintaining the ipp module instead of working only in a fork.
A few weeks ago the first PR's from here were also sent to our fork and I could merge it as it was useful for us.

We also want at least one LGTM before any PR got merged, and all changes should be done with PR's and not directly in master. And adding more tests :-)

The only thing I'm not sure how to make the transition from our fork.
One big PR or start replaying all changes into this repo. WDYT?

[williamkapke]

That's GREAT news! I'd suggest taking the path of least resistance. I'd need to review the diff between the forks to really know how different they are- but as long as semver rules are followed, there shouldn't be an issue. (If major API changes, just do a semver major)

I've added you as a Collaborator here- so you should have push access now. LMK who else to add- or hopefully you can add them now? (not sure)

Also, LMK your NPM username so I can add you there. Also feel free to email me anytime.

[StefanScherer]

Thanks. My NPM username is stefanscherer.

I cannot add collaborators myself, so I think they should comment here if they want to join.

[williamkapke]

Ok You're added to NPM.

Whoops. I had the wrong project open and added you to it by accident. Plz ignore. haha.

[steffanhalv]

Hi, we are working on a project ( StorePilot ) and this will certainly be usefull for us. I would be happy to join the collaboration team if possible, as we would need a working library for many platforms in the coming years. I could not find any other maintained projetcs for this at npm, so what do you think? @williamkapke @StefanScherer

[williamkapke]

I'm very in favor of having more collaborators. What do you think @StefanScherer? If you agree, could you see if you have permission to add folks?

[StefanScherer]

Hi @steffanhalv 👋
I would be happy to have some more collaborators. Some of my colleages probably will join soon as well, but I'm happy to have some "outside" collaborators of our company. I don't want to just switch over to our fork.
For example there should be consensus about code style. We are used to our styling/linting rules (see our fork) which also helped me to find some bugs in this code base. I have seen the GH issue about using the standard code-style and pull request. It is definitely something we have to clarify where we want to go.

Things what I definitely want to have here:

• CI pipeline for Linux (eg. CircleCI) and Windows (eg. AppVeyor)
• have more tests :-)

We recently started to use semantic-release ( https://semantic-release.gitbook.io/semantic-release/ ). See last commits of https://github.com/sealsystems/node-streamparser/commits/master . The advantage is the npm module is released through CI and not directly from individual collaborators.
But the more tools we add the more knowledge must be shared between the collaborators.

@williamkapke I'll check if I have permissions add more collaborators to GitHub and NPM and report back here.

[StefanScherer]

@williamkapke I have checked my permissions. I can add maintainers on npmjs.org, but I don't have permissions to admin the GitHub repo to add collaborators there. This is probably only possible in a GitHub org to let the team members admin the repos.

[williamkapke]

Ah. Hm. Since this is a user account repo (not an org) - I don't see a way to add that.
https://help.github.com/articles/permission-levels-for-a-user-account-repository/

Option 1) Just post a message @-mentioning me to add someone.
Option 2) We can transfer this project to an org.
Option 3) ......? ... I'm open to whatever works best for the project.

Keeping it as a user account repo will probably be an issue with CI administration.

Just LMK what you want to do!

[gewoonwoutje]

@StefanScherer and @williamkapke is this project now deprecated in favor of @sealsystems/node-ipp ?

[StefanScherer]

@gewoonwoutje I'm not working on IPP any more. @sealsystems/node-ipp is currently better maintained, but taking over ownership of this repo and npm module didn't happen yet.