I assume you are referring to hacktoberfest. We did get a few good contributions from that but yeah it's dangerous if any contribution counts.
This got me thinking so I think those issues will need to be very well define - probably even with failing tests if possible.
Also it's probably good to keep the number of bounty issues low for maintainability.
Interesting - I didn't knew that one. It seems very security related - I'm not sure if issues for not supporting a specific part in a spec or for improving documentation for a feature will fit in.
That sounds good. Needs to be very specific and easy to "check". I assume making such well defined bounty issues will require quite some work. If it's worth it only time will tell.
> I also would let the bounties be set by users rather than centrally.
So you mean go to an issue and say I will add another 50 bucks if that get's resolved. Makes sense and will certainly would require a system.
Having a dedicated HR found sound good we have been wondering how to call/do this.
Thanks for sharing your experience - it certainly helped staying realistic. It seems it will not magically lead to all issues being resolved by others. It was a slim hope but yeah probably more a dream then anything . It still seems worth a try
https://issuehunt.io/
- 10% issuehunt fee
- 3.5% stripe fee to deposit also 3.5% to withdraw
- search seems good with filters
- diverse projects
- last tweet in 2019
https://www.bountysource.com/
- 10% withdrawal fee
- search seems limited
- seems to be almost exclusive to crypto
- twitter is active
There are various techniques you can apply in these cases. Like deduplicating dependencies or apply a build/babel plugin that makes sure the names are unique.
Imho scoping elements at the template/element level sounds more promising. Here is an experiment archiving exactly this https://open-wc.org/scoped-elements/
There are still some improvements to be made but it's actively been worked on - so something lion might consider in the future.
hey, one of the devs that pushed for it here. Fully correct - getting everyone on board and then to actually approve it took a long time and a huge amount of effort. Even then although the code was open source we had been in a pilot phase where we have not been allowed to promote it.
But now it's share it is much as you can
And yes we hope to get a big community externally and internally which will improve the components overall
Today we are releasing our first official "Experiment". It potentially allows you to use different versions of the same web-component on one page
In your template it looks normal but under the hood tag names are auto registered.
To get there you need to import side effect free classes and create a special html template literal which will make sure a unique tag name gets used if need be
It comes with a long list of limitations like
️ You can not use self registering elements
️ Every (!!!) component that uses sub components need to use scoped-elements
️ You can not use tag selectors
️ Performance degradation of up to 8%
️ ... see docs
Let's take this as an opportunity start a discussion about nested/scoped elements. You are invited
The docs are quite detailed and should give an idea why this is needed and how it works. More details will follow in a blog post
This got me thinking so I think those issues will need to be very well define - probably even with failing tests if possible. Also it's probably good to keep the number of bounty issues low for maintainability.
Seems there is still much to learn.