Haxelib purge. Is it time to clear the haxelib?

[Creative Magic]

Currently (at the time of this post) there are 991 libraries in Haxelib. Some of those are old, outdated, unfinished, buggy or simply badly named.

I would like to put forward an idea to purge the haxelibs every 6-9 months that do not meet following conditions: 

1. Haxelib was not updated in the last 6-9 months
2. Haxelib was downloaded less than X times (maybe  x=10?)
3. Missing description or very shallow description
4. Library is missing documentation and/or sample(s)

The libraries owner should receive an email that X, Y, Z libraries are to be removed within 2-4 weeks unless they:

• Click a link that would refresh the timer on the libraries
• Update the library
• In case of a bad description, editing the description

I know, the idea has some major flaws: some people are busy or no longer work with Haxe (but their haxelib is useful and good), implementing such a feature takes time and security measures need to be taken to prevent hackers from wiping the haxelib on a whim and some others.

Another idea is to make multiple lists of libraries - the main list is only for well published and popular libraries and the abyss - place where all the forgotten haxelibs resign :)

I do not claim to have the perfect solution, but maybe it's time to think how to clean up haxelib?

[Chii Chan]

curation is a very difficult task, and i m not sure that any proposed measure is going to work.

Is it really that bad to have outdated libraries on haxelib? As long as the metadata is accurate (i.e., the haxe version compatiblity, last updated date, git repo etc), the end-user can make the choice whether to use said library they find, rather than make the author do work to "keep it in haxelib" (which, imho, will just discourage contributions to haxelib).

Not everyone is on the latest version of haxe, and purging old libraries that no longer need updating means existing users of the library will suffer, and yet not give any benefit to any new user (who always have to do their due diligence on the quality of the library anyway).

[Philippe Elsass]

Yeah instead showing a warning on the lib page would be a good idea, but you can't just remove them. 

However, the is currently no way for a lib owner to delete a lib at all. It can come with risks, like the npm left_pad fiasco.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[JLM]

Feel free to remove hxDaedalus, if anyone wants it updated Azarfe7 would need to submit it instead, I don't believe you can change ownership.

[Philippe Elsass]

You can do everything manually in the DB I believe :D

On Thu, Jan 12, 2017 at 10:57 AM, JLM <j...@justinfront.net> wrote:

Feel free to remove hxDaedalus, if anyone wants it updated Azarfe7 would need to submit it instead, I don't believe you can change ownership.

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Philippe

[al...@ruilex.com]

I'd say it is a bad idea to completely remove a library, but totally fine to unlist it from the main list and keep it in the proposed "abyss". 

The reason I think it's good is because having 100 libraries where 5 are working/useful it'a better to have only 5 that are good, IMO.

Having said that I think that realistically nobody's going to delete/unlist existing libs, but maybe we should ask for more strict rules for publishing new libs? I'd say at least one sample is a must. If you can't make the sample work - the lib will probably not be used.

[Jérémy Faivre]

Removing any haxelib sounds like a very bad idea. It would break any project using it, which would be the opposite of what we use a package manager for (afaik): install a project's dependencies easily and reliably.

That said, it's indeed a good idea to reduce visibility of outdated/unused haxe libs in favor of the most popular/updated ones.

On lib.haxe.org, libs are already ordered by number of downloads, which is already a pretty good indicator of whether a library is used or not. Ordering by number of downloads in a specific interval (for example "last 6 months") could improve it even more as it would favor the most used libraries at a current time (and filter out libs that used to be popular, but not anymore).

I personally don't see it as a problem that some libraries are not used anymore, as long as they are not the one that pop up first when searching for things on haxelib. The only issue I see is lib names clashing, which could be solved with namespaces. Not a critical issue though.

[Philippe Elsass]

Totally agree, Jeremy: we need to improve discoverability and relevance by favouring active libs (recently updated, most downloads in the last 6 months, etc.).

Also, ahem, <1k libs is a very minor noise compared to npm's >350k libs :)

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Philippe

[Justin Donaldson]

It would be great to get some kind of flair/number for tests/status that a library might have.  Could we get some metadata from github?  issues?  last commit?  travis badge status?

[dlots]

I am against a purge at this time. 

[Joshua Granick]

I, for one, have wished there was a way to deprecate old libraries I published.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Using Opera's mail client: http://www.opera.com/mail/

[Ben Morris]

Definitely don't purge existing libraries. Not every library needs to be updated every 6 months either, some things simply work and don't require constant updates.

It would be nice if users could log in and rename libraries, transfer ownership, or deprecate their own libraries manually though.

[Philippe Elsass]

It goes without saying that not being able to transfer ownership is a big problem.

Deprecation (as a haxelib warning) sound good.

Philippe

--

[Zaxebo Yaxebo]

I will suggest that not to remove the libraries.
Instead if users could put comments/feedback about individual libraries on their haxelib page then it will be good
For example: The haxelib page of mconsole is http://lib.haxe.org/p/mconsole/  . If on this webpage, the feedback of enduser is available (for example: (Say) that this library works only in this specific case or some ceveat etc of this library) and each comment can be flagged helpful/not helpful/spam. AND also some kind of star rating system of the library by the end users. Then also it will be enough.
Now,
 haxelib showall  mconsole
may show the star rating of the mconsole(say) library and top 5 comments



zax

[Felipe Peternella]

Instead if users could put comments/feedback about individual libraries on their haxelib page then it will be good 

I think this is a must have feature! :)

[Philippe Elsass]

Comments??? Is there any other library repository with that? It risk becoming irrelevant/outdated.

Discussion/comment should be discussed where the source is, like github/bitbucket.

Maybe reporting the activity/number of issues could be a nice addition to haxelib.

--

[Jérémy Faivre]

Comments, rating, [choose your feature] are just decoration, and redundant to what exists on GitHub (or Bitbucket) already.

Getting back to the point: NO it's not time to clear the haxelib. Just making haxelib smarter about discoverability with the data it already has (downloads, data (stars...) fetched from github, ...) would be very nice already.

And being able to transfer ownership seems very useful as well, as it is pretty common that a lib becomes unmaintained by someone, in favor of somebody else.

[Rob Fell]

Let's avoid too much emphasis on #downloads, #stars or even past usage.  Such things aren't always a measure of today's value, they tend to be self propelling and can hinder adaptability or discoverability of originality.

For example, if we applied those filters to programming languages it might be even harder to discover Haxe?

[James Hofmann]

I agree that as pure package vendoring, haxelib is very opaque, and we can't rely on the original maintainers to perfectly represent themselves(I am certainly guilty of some of those ancient packages).

The problem we want to solve with "some packages aren't useful anymore" isn't exactly anything to do with packages themselves - the package system itself functions well, it's just human-unfriendly at scale. What we ideally want is a "solutions" database: Use the combination of packages X, Y, Z in style Q to solve problem J, and here, I'll even do it for you by running this script. In the ideal solutions database, that combination would be the best one for all purposes and there is no need for further thought.

But realistically we have options and trade-offs, so we have to also incorporate a notion of "reviewing", "comparisons", and "tutorialization" - for problem J, solution A vs solution B, and ways to implement it. This is the kind of thing Stack Overflow did: question and answer, and then ratings of the answer, summed into a rating of the user. IMHO, although there are plenty of flaws to any user rating endeavor, people want to make that kind of content and they should have a gamified space to do it in, something that encourages it, and haxelib would be a good centralized system to layer it on. Right now much of our Q+A of this type gets lost in forum threads or IRC. We want the centralization here, the sense of "this is the place you go to find out how to do something with Haxe" .

As well, projects may want to represent themselves as a solution beyond any one package: news on progress, how to get involved, issues, design pitches, indications of API versions encompassed by the larger package, etc. Haxelib could also be extended here to provide some of the services of a Sourceforge or Github, simply by allowing the users to link to or federate existing feeds. Imagine if you could contribute to haxelib projects by linking up information that's already there! It would make Haxe look like a more lively place and reduce a lot of the friction for new users.

I made a little sketch of what this might look like as an interface, when you go to browse for a solution. It's far too incomplete to actually implement,  but it might spark your imaginations for what's possible.

http://imgur.com/a/PORiv

On Wednesday, January 11, 2017 at 4:57:40 PM UTC-8, Creative Magic wrote:

[JLM]

A haxe Github scraper might be a much simpler approach than further customizing haxelib

[al...@ruilex.com]

What about libraries that are simply never finished and published as a test? Should there be a moderator (maybe from the community) that would test libraries time to time and have the power to remove those?

Having an old/deprecated/undocumented library is one thing, but having just some random trash is another. Is there currently any way that spam or even an intentionally placed virus would be removed by a mod/admin?

[JLM]

I am not sure I agree with some of your concerns.

Idea:   Travis passed -> Haxelib update?

However I am curious to know if we could hook toolkits and selected libraries up, so that on passing Travis on github the library was automatically submitted to Haxelib, obviously this may not be relevant to all libraries and should only be allowed for approved authors, but having a submitted by travis tag would keep haxelib's relatively up to date atleast with the main git branch and give you a date and build against which it was tested.  The travis kit could be relatively formalized to use specific haxe version perhaps either nightly or current.

[Alexander Kuzmenko]

Instead of removing we can add some points system. E.g. 1 point for api reference, 1 point for test suite, 2 points for manuals etc. And then users can  estimate which libs are well maintained by total amount of points.

четверг, 12 января 2017 г., 3:57:40 UTC+3 пользователь Creative Magic написал:

[Jérémy FAIVRE]

Honestly, as mentioned before, I don't think any system requiring manual curation is going to work. Who would administrate/moderate each library, to what criteria?

In my opinion, it doesn't make much sense to spend so much efforts on this. I don't believe there would be anybody who could have the bandwidth to curate each released haxelib continuously. The simplest and most straightforward curation I may see is a list of "featured" libs. No need to try to moderate every library. Having unused and outdated libraries is inherent to most package managers with open source libs, and that's OK as long as the most reliable and updated ones are visible (look at NPM, even if it has its flaws too, it works and is used widely). Just providing a "featured libs" or "most popular libs" page would do a nice job.

Actually, half of this work is already done here: http://haxe.org/use-cases/ . It lists "popular" libs for each use case, even though it might not always be up to date as the page is edited 100% manually (but people can already contribute to it!).

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.