-
Notifications
You must be signed in to change notification settings - Fork 78
People attending
If you attend the "Markdown for Science" workshop on June 8th, 2013, please add yourself to this page with the following info:
- your name and contact info (e.g. blog, Twitter or Github)
- your experience/thoughts about using Markdown for authoring scientific content
- what you expect out of the workshop
Martin Fenner (@mfenner)
I am a researcher turned software developer using markdown for technical documentation. I have written two blog posts about this topic (here and here), and have a lot of questions and ideas.
The workshop hopefully helps to build the "Markdown for Science" community with people meeting each other in person and exchanging ideas. It would also be great if one outcome of the workshop would be to pick one of the existing markdown flavors, or to develop a new scholarly markdown flavor. This would make it much easier to develop tools and workflows.
=======
Karthik Ram (@_inundata)
I am a postdoc at UC Berkeley with a strong interest in developing open tools for open science. I've blogged extensively about Markdown and particularly about how it can [revolutionize scholarly communication](revolutionize scholarly communication), enable researchers like me to move away from slow proprietary software. I also write all of my research papers, talks, handouts, and blog posts in Markdown (with the help of Pandoc and Jekyll).
My goal for this workshop is to consolidate best practices for schoarly Markdown.
=======
I'm a PhD student in computer-supported collaborative learning at University of Toronto, been involved in Open Access and Open Educational Resources for many years. Very interested in scholarly publishing, and better tools/workflows for scientists. Developed the very hacky "Researchr" open academic workflow. Recipient of Force11 1k grant, and co-organizer of this workshop.
Interested in helping foster a stronger community around scholarly uses for Markdown/other light-weight markup languages and Git/version control, map all the different tools and initiatives that exist today, and eliminate barriers to adoption. (I'm also in an academic field that is typically a lot less tech-savvy... none of the people in my school of education are using LaTeX, but many of the graduate students use things like Scrivener, and are used to editing wikis etc. They aren't tied into Word, but need something that let's the collaborate with their supervisor, and ideally doesn't require dropping into terminal).
=======
I'm a PhD student in geophysics at SLIM, at the University of British Columbia.
Our laboratory recently began to investigate how one could directly use Markdown for writing documents typically written in Latex. Our main motivations are:
- to have an easier and clearer way to edit documents;
- to be able to convert to different formats;
- to use Markdown as a tool for more reproducible research.
We have run a few tests to see to what extent can Markdown preserve basic functionalities available in other writing languages, as referencing, writing formulas, making bibliographies… We also have done tests on converting Markdown documents to .html, .tex or .docx, notably using Pandoc.
We tried to find ways to cope with Markdown missing functionalities (using Pandoc options and General Purpose Preprocessors). However, we would like to avoid having to use too many personalized add-ons to interpret Markdown language and we would appreciate having some guidelines about a more standardized way to use/extend this tool.
=======
I am a graduate student at UC Berkeley and have been using Markdown within the IPython Notebook to simultaneously write up the formal math and implement the corresponding code for my models. I really love this workflow, but I'd love to see (or learn about) slightly better integration between Markdown and LaTeX. I'd be interested in developing or contributing to a tool that would make it easier for people unfamiliar with LaTeX, for example, to format documents written in Markdown with an arbitrary LaTeX template provided by a conference/journal.
========
M. Jackson Wilkinson (@mjacksonw)
I'm primarily a product designer/user experience fella' (and a developer too), founder of MDaybook and Kinsights, both of which use Markdown as primary input mechanisms, the former of which handles a lot of scholarly-style content. I'm a big believer in the promise of Markdown, but think it has a ways to go to really satisfy the scholarly use case. I'm interested in helping ensure that scholarly extensions maintain the simplicity and usability that's drawn us all to Markdown in the first place.
========
Science guy at Creative Commons. Customized portions of Gruber's original markdown.pl power punkish.org with adaptations modeled after Fletcher Penney's mmd.
Let's talk about stackedit that brings roundtrip markdown to Dropbox and Google Docs. Also, citations (perhaps hooks into repo managers such as Pages, BibTex, etc.), and offline editing.
There is also Draft that purportedly does version control.
My attendance will be a bit abbreviated because of the concurrent State of the Map, but am looking forward to the meeting.
========
Greg Jordan (@gjuggler)
I'm a former researcher in comparative genomics, now a software developer for Paperpile (a web-based reference manager). I haven't used markdown extensively before, but we have thought lots about the future of scientific writing and how simple standards could help push things forward. I'll bring the perspective of a potential adopter who would use this to build end-user writing tools. Furthermore, I'll advocate for some amount of machine-readability, which may require a delicate balance to jive with the simplicity / flexibility for which markdown is known.
========
Kaveh Bazargan (@kaveh1000)
I run River Valley Technologies, a composition business based in UK and India. We use TeX/LaTeX as our pagination engine. (I have used TeX since it first appeared.) I am aware that not everyone is going to use LaTeX, so we need a simple mark-up that helps the non-TeX user. MarkDown seems a good possibility.
========
Jonathan Frederic (@GooseJon)
I'm an IPython core developer. IPython provides a rich architecture for interactive scientific computing. My area of focus is NBConvert, a utility that converts IPython Notebook files to and from HTML, Sphinx Latex, RST, Reveal, etc. The IPython Notebook relies on Markdown for text formatting. The whole team and I have had to work with Markdown. We've extended Markdown by adding some features that don't exist. We try to follow GitHub's Markdown flavor where possible. My hope for this workshop is that we can come to agreement on a standard Markdown notation for these types of extensions..
========
Zach Sailer (@Zrsailer)
I’m a PhD student in physical chemistry at the University of Oregon (starting this Fall) and an IPython core developer. IPython currently uses Markdown for text formatting in its HTML notebook. An attractive application of these notebooks is their ability to promote reproducible science and research. Users can write code to analyze and plot data, while annotating and explaining their work in Markdown cells between blocks of code. We would like to see Markdown cover more ground in presenting scientific content. Ideally, Markdown would relieve us from using Latex in the notebook and easily display equations, tables, bibliographies, and figures.
========
Molly Sharp (@sharp_molly)
I'm a new product manager at PLOS, with a focus on improving our content management systems. Before that, I worked in book publishing since the mid-90's, managing production systems and workflows. I was an early adopter of an XML workflow, for a tech publisher back in '99. These days I'm thinking XML-first workflow is overkill for most types of publishing. I am leaning towards an HTML-first workflow myself because I think the industry will be developing fantastically easy-to-use, Word-like editors for browsers with commenting and all the other features that tie authors to Word (whether they like it or not). But I want to learn more about Markdown. While I like the benefits (lightweight structure separated from formatting), I've had bad experiences actually getting authors to work with it, so I'd like to learn your ideas about how to get over that hurdle. And I'm new to scholarly publishing, so you all will be helping me by putting these particular challenges on my radar.
========
Mitar Milutinovic (@mitar_m)
I am a PhD student at UC Berkeley where I work on improving the ways we collaborate. Together with others at The Open Access Initiative at Berkeley we are developing PeerLibrary, a web platform for collaboratively discussing and note taking around open access literature.
I am attending the event to argue against using Markdown for scientific purposes. HTML/XML with semantic tags provides not just structure and machine-readability but possible ways to semantically tag the content. In 21st century there is really no reason anymore for anybody to write directly in a machine readable format but could use easy to use GUIs and leave GUIs to save content in the open machine readable format in the background. Mental gap between Markdown and HTML is much smaller than between GUI and Markdown. Requiring from people to learn a markup language is a big requirement. Why not just create a nice GUI meant for scientific content?
========
William Gunn (@mrgunn)
I am the Head of Academic Outreach at Mendeley and work in their altmetrics and reproducibility projects. I was an attendee at the first Beyond the PDF and am interested in scholarly markdown as a flexible and low entry barrier means to publishing on the web. I'm interested in learning about author and reader needs and best practices at this event.
========
Felix Breuer (@felixbreuer)
I am a postdoc in mathematics at San Francisco State University and author of a minimalist open source editor called Qute that supports Markdown syntax plus TeX formulas and features per-paragraph preview of the text. For the purposes of Qute, I'd like to see and contribute to the development of a standard Javascript library for processing Markdown that supports TeX formulas (e.g. via MathJax) and that can be used to typeset individual paragraphs of a larger document. On the whole, I do not see Markdown as the future scientific document format. Rather, I think the future lies with open, extensible document formats that can host text, code, and data side-by-side - in the spirit of IPython, Sage, or Substance.
=======
Ana Nelson (@ananelson)
Ana is the author of dexy, an open source tool for free-form document automation.
=======
Jakob Voß (@nichtich)
I'm a library and information scientists and developer at the common library network (GBV) in Göttingen, Germany (that's why I cannot physically attend the workshop). After heavily using MediaWiki for a decade, I started more and more using Markdown syntax and I closely followed the development of Pandoc. To facilitate the creation of papers, slides, and specifications in Markdown, I created a toolkit for Automatic document generation. See makedoc and makespec - right now makespec is more elaborated and makedoc is primarily used to create slides. I would like to see more use of (Pandoc) Makdoc for documents also because it facilitates versioning and transparency.