Forking the project, patches welcome at: getUserBarcode

[kristate]

This project has not been updated for awhile and we would like to welcome everyone's patches onto a new fork at https://github.com/NeraiCorp/getUserBarcode

/ref #291

[serratus]

@kristate Thanks for the wake-up call. Do you, or anyone else want to take over the project maintenance?

I'm sincerely sorry for abandoning this project and turning a blind eye on the community. Looking back, it was a selfish act, but by the time I've decided to turn away from quagga it was the only choice I think I had to keep myself sane.

Now, better late than never, I would like to officially hand over this project.

[TomasHubelbauer]

@kristate Please consider accepting the maintainership and continue in this original repo as to not fragment the community. I see that you have merged 5 patches so far so hopefully it will not be that much work lost if you decide to take over maintaining Quagga.

[serratus]

The question becomes if I should transfer the repository to a new "organization" or to someone's (@kristate) personal account, or if collaboration is sufficient. If anyone else is interested in becoming a collaborator, please speak up. My plan is to not further delay this process.

[TomasHubelbauer]

@ericblade you might potentially also be interested in this?

I'd like to offer myself as a fallback collaborator if no one else steps up. I don't have experience with running a bigish open source project like this, but I'd hate to see a fork spring up if it can be helped.

I wouldn't mind the repo moving to a new owner, but unless required by a new maintainer, I don't see why to do it. It's perfectly normal for a repo owner to step away from a project they are no longer interested in / able to actively maintain and let the new maintainers operate on the original repo - and if it is to be associated with a personal account, I think it's best for it to be the founder's one. I do think an organization would be an overkill.

[ericblade]

Hi all :-) Glad to see @serratus is OK. Although I'd be willing to be involved, I think it'd be better for someone who's more involved in the code, if there's anyone else that is interested. I'd probably be more of an integrator, than a contributor, image processing isn't exactly a point i'm experienced in. I can argue about style and general code quality all day long (and sometimes do ;) ) but my skillset doesn't make me any more qualified than any random javascript developer.

Unless serratus intends to step out again just as quickly as he stepped back in, then I think his input should be what matters the most. Whatever ultimately happens, I would just like to make sure that the code will stay alive, and that hopefully people can get into it again.

I suspect from a technological standpoint, it'd probably be easier to add some collaborators with full access to the existing repository -- there are over 400 forks, 8 existing pull reqs, who knows how many potentially good and useful commits across all those forks that could be pulled.. and it'd probably be easier to integrate them from here, than to get people to all rebase to a new remote. As well, the process of renaming everything, and essentially having a dead line of code in existence..

Another question I have, is about the npm repo.. I haven't yet published anything of importance to npm myself, so I don't know how that process works -- if that's an easy thing to transfer to collabs, then I'd definitely think that keeping the code repo right here is best. I think that making a total fork, with new repo, new names, new everything, is a lot of extra effort that just makes things confusing, and doesn't serve a community well, unless there's a really good reason to fork where the positives outweigh the negatives.

Are there any previous contributors that are interested? People who already maintain a fork? Since serratus is here right now, I think we should have a discussion wrt whoever wants to be maintainer/collaborator now, rather than just imposing "ok here's the new place to be".

I don't have any reason to particularly recommend or not recommend @kristate / @NeraiCorp .. just think we should look to the options out there, get 1 or 2 collabs, and then serratus can wash his hands of the whole thing, if he wishes.

[TomasHubelbauer]

// Run this in your DevTools Console for an `about:blank` page (to work around CSP restrictions).
// The GitHub API has strict limits, do not want to run out while experimenting, so cache for tweaking.
var dataCache; // Declare as `var` so it can be redeclared while tweaking the script and rerunning
void async function() {
  if (!dataCache) {
    const response = await fetch('https://api.github.com/repos/serratus/quaggaJS/forks');
    const data = await response.json();
    dataCache = data;
    console.log('Cached.');
  }

  const size = 95284; // https://api.github.com/repos/serratus/quaggaJS -> size
  console.log('Bigger by size\n', dataCache.filter(fork => fork.size > size).map(fork => fork.html_url).join('\n '));
  const pushed_at = new Date('2018-01-26T16:24:37Z'); // https://api.github.com/repos/serratus/quaggaJS -> pushed_at
  console.log('Bigger by pushed_at\n', dataCache.filter(fork => new Date(fork.pushed_at) > pushed_at).map(fork => fork.html_url).join('\n '));
  const updated_at = new Date('2018-05-31T23:39:36Z'); // https://api.github.com/repos/serratus/quaggaJS -> updated_at
  console.log('Bigger by updated_at\n', dataCache.filter(fork => new Date(fork.updated_at) > updated_at).map(fork => fork.html_url).join('\n '));
}()

Bigger by size
 https://github.com/NeraiCorp/getUserBarcode
 https://github.com/gigarza/quaggaJS
Bigger by pushed_at
 https://github.com/NeraiCorp/getUserBarcode
 https://github.com/gigarza/quaggaJS
Bigger by updated_at
 https://github.com/fuzhengyi/quaggaJS

Pinging @NeraiCorp, @gigarza and @fuzhengyi as they seem to be maintaining the most active forks.

(Unfortunately there doesn't seem to be an easy way to see the above metric for commits and also these metrics operate on the default branch, so this will not reveal activity in PRs probably. I did this thru the API because there is too many forks to do this manually. People seem to create "security forks" as a way to bookmark projects without ending up with dead links.)

[serratus]

@ericblade @TomasHubelbauer I appreciate your efforts. I've also added both of you as collaborators. There is still a chance for me to get back into the game, but that won't happen anytime soon. Personal and professional reasons keep me from doing that in the near future. I'm a big believer in Open-Source and benefit from it on a daily basis, but sometimes it just consumes your life more that you realize, until it's too late.

I'm happy to help anyone who is interested in getting more involved, however, my time is very limited, but I still want the transition to be smooth.

[ericblade]

What I'd like, then, is a quick tutorial on how to go about operating a development branch with my code (I use quagga in browser, with React) .. as well as a quick tutorial on how to go about any other processes that would be interesting to an integrator type role.. i see there's already how to build and how to test in the readme, so I guess would just need the process for shipping a new version to npm/bower (does bower use a different repo or does it just do npm stuff differently? i've never used it)

I happen to be a big fan of automatic CI and testing processes, so if I have some time to do some of that, I'd love to.

[TomasHubelbauer]

Thanks, @serratus, same as @ericblade, I'd also like to see some sort of a write-up or we can just chat and me and/or Eric will put it to writing here in the repo as docs. I can help with the NPM deployment as I've deployed some smaller packages (you will need to add me and Eric as package owners on NPM for us to be able to deploy - using npm owner add). I'm not that great with merging patches and stuff, though, so hopefully you Eric will be able to help there?

There's no rush, though - please, prioritise your well being, that is the most important thing.

[ericblade]

I'm going to go ahead and create a gitter chat, then, since that's pretty convenient.

https://gitter.im/quaggaJS/Lobby#

[kristate]

@serratus, @TomasHubelbauer, @ericblade

I am glad to see that everyone is passionate about this issue and also glad that @serratus has been very forthcoming in supporting this community into its next chapter.

My opinion falls as so:

• Barcodes are going to become more popular than anyone has imagined
• The web needs barcode infrastructure
• This project has seemingly grown larger than one person

Therefore, I recommend to:

• Place / move this project into a new Organization (similar to @zxing).
• Create a Roadmap and Milestones
• Work with the @w3c on standardization: navigator.getUserBarcode
  • Many platforms already support barcodes natively, why not browsers?

I understand that the Quagga naming is a play on Zebra and @zxing, but I think by working on standardization, this project could help lead the effort to getting native barcode support built into all browsers.

I look forward to everyone's thoughts. I have registered the @getUserBarcode org and if @serratus decides to hand over the project, I will work on the above items to completion.

Thank-you for your time and consideration.

kristopher

[ericblade]

That's certainly ambitious. I have no problem with any of that, I think it'd be great. I doubt that W3C would be interested in it, but I could be wrong. Seems a bit outside of their domain. I'd certainly back it.

[rajbdilip]

I don't have much experience myself in image processing (and with Quagga itself; I have just started to tinker with it) but I'd love to help in any way I can.

[TomasHubelbauer]

I think we can close this issue now. @kristate I don't think we will be able to achieve what you have described in your comment, perhaps your fork will do better, I certainly don't see how we could attract the talent required to make that happen or how to ourselves make time to work with a standardization body constructively short of receiving a grant or something. We can call your fork out in the README as an alternative if you are going to maintain it?

@rajbdilip we appreciate this offer, I would personally suggest, if you will find yourself with a bit of spare time you'd be willing to dedicate to this project, for you to go through the existing issues and help us sort out which ones are still reproducible and which ones are not. That'd be big help.

@ericblade how do you feel about us closing this issue and potentially linking to Kristopher's fork should he confirm his commitment to maintaining it?

[rajbdilip]

@TomasHubelbauer Sure. Looking forward to it.

[ericblade]

I would also welcome @kristate working with the existing project, if he wants to use it as a test bed for presenting to a standards body, or what not, i'm all for supporting that. I don't see a need for a separately maintained fork, unless he wants to go in a wildly different direction, and I don't think we have really put together any sort of a direction for this project currently . . . I'm not sure if @serratus might have any input on any directions he wanted to go with it, that isn't buried in the Issues section here.

[iFlash]

@serratus I would STRONGLY suggest you reconsider not taking quagga to the next level. AFAIK it is the only project that does bar code recognition in JS available to the public.

I use it extensively on retroplace.com (retro gaming website) and I just love it. It has minor issues but works just wonderfully with any device I tested (that is capable of doing barcode recog in the first place).

[mobilemike73]

This appears to be a beautiful solution but I'm getting a very high error rate decoding UPC-A barcodes.

[braindigitalis]

This is great news, I am glad to see the project back alive again. I'm yet another developer with no real experience of image processing, but if there's anything i can do to contribute, please let me know.
We use this library in commercial software so it wouldnt be a stretch for us to contribute any fixes and tweaks back to the community.

[ericblade]

We are most definitely accepting patches here, @TomasHubelbauer and I are paying attention. I'd definitely welcome any improvements. I know there's a couple of pull requests in the pipe here, but I've asked for some changes to them, so haven't merged.

[ericblade]

@serratus @TomasHubelbauer @kristate

I think it's time to revisit this question here -- given the recent incidents that have happened in the npm community, i am no longer of the opinion that maintaining the link to the original package is necessarily the best option. Christoph and the rest of the user base has no specific reason to trust or not trust any of us here, though that was the crux of my original argument -- maintaining the trust of the users by not moving things. However, no matter which side of that discussion is better (and that's debatable especially given recent incidents), as far as I know, without at least a little more action from Christoph, wrt npm permissions, we can't really proceed.

Therefore, I'm willing to support @kristate if he's still interested in proceeding. I would also be interested in helping, I can maintain a fork, if necessary. No one here has any specific reason to trust or not trust me, as far as I'm aware, although I am making an effort to help in the Issues and Pull Reqs category here as much as I can. I'm a user of Quagga, and it's something that my current personal project really depends on, so I have a definite interest in seeing it thrive, as there doesn't seem to be anything resembling another option out there.

I would rather that someone who has the knowledge to really improve upon it with new features and such take the reins, versus me. But I'll do it if no one else wants to.

[TomasHubelbauer]

I have come around on the topic as well and a GitHub org sounds like something which would be a logical next step if we want to keep the project alive and competitive, so therefore I am in favor of setting one up. I checked @kristate's fork and it looks like it's no longer maintained (but maybe there was not a lot of maintenance to be made), but if it springs up again, that would be a good place to continue development too.

[ericblade]

I'm willing to try out whatever will be necessary to get Quagga moving again. It appears that some code will need to be reworked to deal with recent changes in Safari, and/or some clarifications made on exactly how to deal with the current state of mobile.. i'd definitely like to move forward with a branch that eliminates any older cruft, gets testing sorted out, etc. So, I just want to do whatever I can to get more forward motion going. Whether that be just throwing out a Quagga2 repo and npm lib, and moving from there, or starting an org, or whatever. @kristate definitely had some ambitious ideas, and I hope we didn't sour the whole thing on him by trying to work it out in this repo first.

[rajbdilip]

So, how are we moving forward? We create an organization or continue with @kristate 's repo?

[nitinsbuzz]

This topic is also active on gitter. Pls lets all use the same com channel in moving this project to the next phase.

[kristate]

Happy New Year everyone -- let me circle around to check comments and I will reply.

Thank-you.

[obedm503]

given the recent events with event-stream, I would suggest archiving this repository and continuing with a fork under a different npm name