You know how the API design guidelines [1] talk about designing for a concrete use case? It applies to talks, too. If you can talk about how you're using Elm, or something interesting you've done with it (either an experimentation or a shipped project) you're going to have a much better chance of being accepted than something that's just "well, here's a cool thing I'm gonna talk around for 40 minutes." It'll help in actually writing and giving the talk too.
[1]: http://package.elm-lang.org/help/design-guidelines On Monday, June 27, 2016 at 2:59:02 PM UTC-5, Peter Damoc wrote: > > Taxonomy of components. > > How can we expand on the elm-lang/html and the Elm Architecture in a way > in which we can create reusable components that fit well together. > > elm-parts is a project that came out of the elm-mdl effort. > Maybe you could talk about something like that. > > > > > > On Mon, Jun 27, 2016 at 9:27 PM, Joe Andaverde <joe.an...@gmail.com > <javascript:>> wrote: > >> With the simplification of Elm since 0.17 it seems like there are far >> less intermediate+ possible talks. I imagine the best talks will be about >> tooling and not so much about the using the language. >> >> What are some topics worth speaking about that are "beyond the basics"? >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elm-discuss...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
