I think it might be worth making some more "meta" issues, like Tim Holy's test coverage one, that are new person friendly. Things like "Code Cleanup", for the stuff Jake Bolewski was working on in LinAlg, or "Better Error Messages" so if you get a DimensionMismatch you know which dimensions were mismatched, or "More Comments on Tests". You could make a checklist of files to look at in the issue, so that someone new can easily see where in base needs work and have other files to compare to.
On Friday, 8 May 2015 09:25:23 UTC-7, Isaiah wrote: > > There are now 13 issues with the "intro issue" label. I would be > interested in any comments on how people feel about the calibration of > these. > > I have to say that after looking through a large fraction of the open > issue list (titles), I basically agree with Stefan's assessment in the > other thread that the truly low-hanging fruit gets dealt with pretty > quickly. In part this is because we have developed a reflexive response of > saying "want to submit a pull request?" when such an issue is submitted -- > which usually does elicit a PR from the submitter or someone else in fairly > short order. > > On Fri, May 8, 2015 at 6:41 AM, Tamas Papp <[email protected] <javascript:> > > wrote: > >> 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] <javascript:>> 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] >> <javascript:>> 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 >> >> >
