Maybe I missed a a more recent thread but I would like how things are going for the packages organization. It is currently hard to look for a package when you know what functionality you're looking. It is even harder when you look for something general.
What about a tag list ? (keywords associated with each submitted package would be a plus of course) And the clustering by theme would be nice (like all the package related to geometry, to plots and so on). Best, Jeff Le vendredi 30 janvier 2015 08:45:12 UTC+9, Ken B a écrit : > > I have found the "curated deibans" by research topic from svaksha very > useful when looking for a certain method: > https://github.com/svaksha/Julia.jl > > +1 Steven Sagaerts comment on less is more, coming from an experienced R > user. > > > On Thursday, 29 January 2015 23:13:37 UTC+1, Stefan Karpinski wrote: >> >> I think the approach should be to add keywords/labels to the package >> metadata. >> >> On Thu, Jan 29, 2015 at 3:18 PM, Hans W Borchers <[email protected]> >> wrote: >> >>> I absolutely agree, and your description is very helpful in >>> understanding what >>> a Julia organization shall be. >>> >>> But see, then Julia organizations are not an "equivalent to CRAN Task >>> Views". >>> There should exist something inbetween an organization and the package >>> list, >>> maybe a classification associated to the METADATA, as Sean mentioned, or >>> something else (I don't know what). >>> >>> >>> >>> On Thursday, January 29, 2015 at 8:50:32 PM UTC+1, Jiahao Chen wrote: >>>> >>>> Organizations only make sense when there are: >>>> >>>> a) a critical mass of contributors focused around a common theme, and >>>> b) the theme is sufficiently focused to the extent that common code >>>> infrastructure can be shared and reused. >>>> >>>> Correct me if I'm wrong, but I simply don't see how the proposed list >>>> of packages form a coherent organization. >>>> >>>> Note that we already have several core numerics packages under the main >>>> JuliaLang organization, and progress has been slow and unsteady. I say >>>> this >>>> not to criticize our contributors. Quite the opposite, it takes a lot of >>>> courage to even try, and every bit is much appreciated. The problem is >>>> simply that good numerics code is hard to evaluate, write, verify and >>>> maintain, and few of us are in the business of core numerical algorithms. >>>> >>> >>
