-1 on trying to put plans, schedule, roadmap on the website. "This week in Julia" was a great contribution to the community but evidently took more effort than Matt had time to keep up with.
New features get developed as the PR's for them get worked on and finished. You can subscribe to just the subset of issues/PR's for things you (along with everyone else) are eagerly awaiting. Better yet, help with testing and code review if you can. We have been doing a good job of monthly backport bugfix releases, we should be able to continue doing that. But 0.4 is still unstable and has several big-ticket items still open and being worked on (check the milestones on github). It's too early to try to make time estimates, if people are impatient and want a release sooner it's not going to be possible without punting on a number of targeted features and pushing them back to 0.5 or later. On Wednesday, December 10, 2014 1:58:52 PM UTC-8, Randy Zwitch wrote: > > I think it would please everyone if you moved daily televised scrums. > > > On Wednesday, December 10, 2014 4:53:50 PM UTC-5, John Myles White wrote: >> >> Stefan, I shared your moment of terror about the idea of posting plans >> (essentially all of which will be invalidated) to the home page. >> >> Although it's huge volume of e-mail, I do feel like people who want to >> keep up with new developments in Julia should try to subscribe to the issue >> tracker and watch decisions get made in real time. It's a large increase in >> workload to ask people to both do work on Julia and write up regular >> reports about the work. >> >> -- John >> >> On Dec 10, 2014, at 1:48 PM, Stefan Karpinski <ste...@karpinski.org> >> wrote: >> >> I have to say the concept of putting plans up on the home page fills me >> with dread. That means I have update the home page while I'm planning >> things and as that plan changes and then do the work and then document it. >> It's hard enough to actually do the work. >> >> On Wed, Dec 10, 2014 at 4:44 PM, David Anthoff <ant...@berkeley.edu> >> wrote: >> >>> +1 on that! Even vague plans that are subject to change would be great >>> to have. >>> >>> >>> >>> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On >>> Behalf Of *Christian Peel >>> *Sent:* Wednesday, December 10, 2014 10:15 AM >>> *To:* julia...@googlegroups.com >>> *Subject:* Re: [julia-users] Re: home page content >>> >>> >>> >>> One thing that I would very much appreciate is some kind of development >>> schedule. For example >>> - Some kind of general roadmap >>> - a plan for when 0.4 and future releases will come >>> - Any plans to switch to a regular schedule? (yearly, six >>> months, ...) >>> - What features remain before a 1.0 release? >>> - When will following arrive? >>> > faster compilation >>> > pre-compiled modules >>> > Interactive debugging; line numbers for all errors >>> > Automatic reload on file modification. >>> > Solving P=NP >>> >>> I know that it's tough to make such a schedule, but anything that you >>> can provide would be helpful. Also, I'd be happy for something like a >>> weekly update; or a weekly blog post to help those who don't peruse this >>> group in depth each day. >>> >>> Thanks! >>> >>> Chris >>> >>> On Wednesday, December 10, 2014 5:41:35 AM UTC-8, Tamas Papp wrote: >>> >>> From the discussion, it looks like that homepages for programming >>> languages (and realed projects) serve two purposes: >>> >>> A. provide resources for the existing users (links to mailing lists, >>> package directories, documentation, etc) >>> >>> B. provide information for potential new users (showcasing features of >>> the language, links to tutorials). >>> >>> Given that space on the very front page is constrained (in the soft >>> sense: no one wants pages that go on and on any more), I think that >>> deciding on a balance between A and B would be a good way to focus the >>> discussion. >>> >>> Once we have decided that, we can shamelessly copy good practices. >>> >>> For example, >>> >>> 1. the R website emphasizes content for existing users (in a non-flashy >>> way that I am OK with), with very little material for new users, >>> >>> 2. about 1/3 of the middle bar on >>> https://www.haskell.org/haskellwiki/Haskell is for new users >>> (explanations/tutorials/etc), the 1/3 is for existing users (specs, >>> libraries), and the final 1/3 is for both (forums, wiki, etc), >>> >>> 3. http://new-www.haskell.org/ is mostly caters to potential new users >>> ("see how great this language is"), >>> >>> 4. the content of clojure.org is similarly for potential new users, >>> while the sidebar has links for existing users. >>> >>> Best, >>> >>> Tamas >>> >>> On Wed, Dec 10 2014, Hans W Borchers <hwbor...@gmail.com> wrote: >>> >>> > Look at the R home page. R is one of the most popular languages, and >>> esp. so >>> > for statistical and computational applications. A programming language >>> does >>> > not need bloated home pages. >>> > >>> > I like the old Haskell home page much more than the new one. The new >>> one >>> > has >>> > large, uninformative background pictures and not much information in a >>> > small >>> > and readable view. The HaskellWiki front page was much better in that. >>> It >>> > may >>> > not even be decided which version will win. >>> > >>> > [Clojure])http://clojure.org/) has a nice, simple and informative >>> home >>> > page, >>> > while [Scala](http://www.scala-lang.org/) has overdone it like the >>> new >>> > Haskell. For other approaches see the [Nim](http://nimrod-lang.org/) >>> - >>> > formerly 'Nimrod' - and [Nemerle](http://nemerle.org/) home pages. >>> > >>> > In the end I feel the condensed form of the Python home page will >>> attract >>> > more interest, for example with 'latest news' and 'upcoming events' on >>> the >>> > first page.This gives the impression of a lively and engaged >>> community. >>> > >>> > >>> > On Wednesday, December 10, 2014 11:23:37 AM UTC+1, Tim Holy wrote: >>> >> >>> >> I like the Haskell one better than the Rust one. >>> >> >>> >> --Tim >>> >> >>> >> >>> >>> >> >>
