I am a Julia newbie, currently diving into the internals so that I can contribute later. Many design features of Julia are novel, and in flux, which makes it harder to contibute. Even when an issue seems simple, I am always concerned that there are ramifications I don't yet understand. Identifying issues which don't require such a deep understanding of Julia would be great.
So I would find Tim's suggested interpretation of the "newbie" label practical and useful. Best, Tamas On Fri, May 08 2015, Tim Holy <[email protected]> wrote: > While I agree that "easy" is not always easy to define, I also think that > there > is real merit in flagging issues that should not require a deep dive into > internals. For many first-time contributors, just learning git and GitHub is > quite a barrier in itself (it was for me). A one-line fix---like adding a > missing method---is the perfect warmup exercise. To a potential contributor, > s/he presumably has better access to "what am I good at?" than to "what > issues > will not require three days of work even by someone with expertise in Julia's > innards?" > > --Tim > > On Friday, May 08, 2015 10:33:48 AM Mike Innes wrote: >> Part of the issue is figuring out what "Newbie" means. New to programming? >> Experienced in programming, but new to Julia? Experienced in Julia, but new >> to Base? New to open source? Arguably all of these are valid targets, but >> mixing them together ends up not being that helpful since people still have >> to sort through them. >> >> I agree with what Tomas has said about writing packages. I can definitely >> understand people wanting to contribute to Base, but if you just want to >> get some code out there and/or get a taste of the process contributing to >> packages will be much quicker and easier. >> >> The great thing about Julia's early stage is that (a) it's really easy to >> find holes in functionality and (b) if you fill those holes, chance are >> you'll have "the package" for that functionality, and people are actually >> going to use it. On top of that, you're much more likely to be interested >> in the work. That's a really great opportunity IMO. >> >> It's easy enough to pick something you're interested in and, depending on >> your level of confidence, start from scratch, port it from another >> language, experiment, whatever. As one option, the web stack is >> particularly ripe for development right now. (Which is a polite way of >> saying that there isn't much of one.) >> >> On 8 May 2015 at 07:03, Tomas Lycken <[email protected]> wrote: >> > I just want to put some emphasis on what Scott hinted at: if you want to >> > contribute to Julia, start with figuring out what *you* know a little >> > about. >> > >> > Sometimes there's code in base that does some of those things, but not all >> > of them, and/or not as well as you know how to. >> > >> > Sometimes there's not a place in base for your problem domain, but I've >> > found that contributing to a package (or building a new one) is just as >> > good a way to get started writing some Julia code. And chances are pretty >> > high that after a while you stumble upon something in base that needs >> > improvement for your package development to be as easy as possible - >> > voila! >> > We've found someplace in base for you to contribute :) >> > >> > Bottom line is, it's usually pretty easy to write Julia code as long as >> > you know what the code should do - the hard part is finding something that >> > you know how to do (and where to put the code that does it). >> > >> > // T
