We might want to link to canned searches on GitHub to issues that are
relevant. For example, we do use milestones to categorize issues so we
could link to stable release issues and development release issues. That's
not quite a roadmap but it does help to give visitors some clue about
what's in the works without adding to the burden for developers (since
we're already using the milestones for organizational purposes).

On Thu, Dec 11, 2014 at 10:50 AM, John Myles White <johnmyleswh...@gmail.com
> wrote:

> This is a very good point. I'd label this as something like "core unsolved
> challenges". Julia #265 (https://github.com/JuliaLang/julia/issues/265)
> comes to mind.
>
> In general, a list of the "big" issues would be much easier to maintain
> than a list of goals for the future. We could just use a tag like "core" on
> the issue tracker.
>
>  -- John
>
> On Dec 11, 2014, at 4:49 AM, Mike Innes <mike.j.in...@gmail.com> wrote:
>
> It seems to me that a lot of FAQs could be answered by a simple list of
> the communities'/core developers' priorities. For example:
>
> We care about module load times and static compilation, so that's going to
> happen eventually. We care about package documentation, which is basically
> done. We don't care as much about deterministic memory management or TCO,
> so neither of those things are happening any time soon.
>
> It doesn't have to be a commitment to releases or dates, or even be
> particularly detailed, to give a good sense of where Julia is headed from a
> user perspective.
>
> Indeed, it's only the same things you end up posting on HN every time
> someone complains that Gadfly is slow.
>
> On 11 December 2014 at 03:01, Tim Holy <tim.h...@gmail.com> wrote:
>
>> Really nice summaries, John and Tony.
>>
>> On Thursday, December 11, 2014 02:08:54 AM Boylan, Ross wrote:
>> > BTW, is 0.4 still in a "you don't want to go there" state for users of
>> > julia?
>>
>> In short, yes---for most users I'd personally recommend sticking with 0.3.
>> Unless you simply _must_ have some of its lovely new features. But be
>> prepared
>> to update your code basically every week or so to deal with changes.
>>
>> --Tim
>>
>>
>
>

Reply via email to