Category Archives: discussion

Improving Software Citation and Credit BoF session slides

On Tuesday, October 27, the ASCL held a Birds of a Feather session at ADASS on Improving Software Citation and Credit. The session was opened with a brief presentation by Bruce Berriman, who reported on a Software Publishing Special Interest Group meeting held at the January 2015 AAS meeting and the ongoing work that has come out of that. I followed with a quick overview of other efforts to improve software credit and citation, not just in astronomy but across disciplines, after which Keith Shortridge moderated a lively discussion among the forty people present. The slides Bruce and I presented are now available online.

Previously, we shared resources for the session and the Google doc created during the session to capture some of the main points from the discussion.

Resources for ADASS Birds of a Feather session: Improving software citation and credit

The ASCL has organized a Birds of a Feather session (BoF) at ADASS to discuss improving software citation and credit to be held on Tuesday, October 27; the following links may be helpful for the discussion.

Astronomy-specific
Astronomy software citation examples and ideas (working [Google] document arising from AAS SPSIG discussion)

Astronomy software indexing workshop

Cross-disciplinary
Workshop on Sustainable Software for Science: Practice and Experiences (WSSSPE)

Force11 Software Citation Working Group (Mission statement, member list, timeline, communications plan, etc. on GitHub)

Center for Open Science‘s Transparency and Openness Promotion (TOP) Guidelines

 

Google doc created during the BoF session; anyone with the link can comment.

Licensing Astrophysics Codes session at AAS 225

On Tuesday, January 6, the ASCL, AAS Working Group on Astronomical Software (WGAS), and the Moore-Sloan Data Science Environment at NYU sponsored a special session on software licenses, with support from the AAS. This subject was suggested as a topic of interest in the Astrophysics Code Sharing II: The Sequel session at AAS 223.

Frossie Economou from the LSST and chair of the WGAS opened the session with a few words of welcome and stressed the importance of licensing. I gave a 90-second overview of the ASCL before turning the podium over to Alberto Accomazzi from NASA/Astronomy Data System (ADS), who introduced the panel of speakers and later moderated the open discussion (opening slides), after which Frossie again took the podium for some closing remarks. The panel of six speakers discussed different licenses and shared considerations that arise when choosing a license; they also covered institutional concerns about intellectual property, governmental restrictions on exporting codes, concerns about software beyond licensing, and information on how much software is licensed and characteristics of that software. The floor was then opened for discussion and questions.

photo of audience at licensing session

Discussion period moderated by Alberto Accomazzi

Presentations
Some of the main points from each presentation are summarized below, with links to the slides used by the presenters.

    • Copy-left and Copy-right, Jacob VanderPlas (eScience institute, University of Washington)
      Jake extolled everyone to always license codes, as in the US, copyright law defaults to “all privileges retained” unless otherwise specified. He pointed out that “free software” can refer to the freedoms that are available to users of the software. He covered the major differences between BSD/MIT-style “permissive” licensing and GPL “sticky” licensing while acknowledging that the difference between them can be a contentious issue.
      slides (PDF)
    • University tech transfer perspective on software licensing, Laura L. Dorsey (Center for Commercialization, University of Washington)
      Universities care about software licenses for a variety of reasons, Laura stated, which can include limiting the university’s risk, respecting IP rights, complying with funding obligations, and retaining academic and research use rights. She also covered factors software authors may care about, among them receiving attribution, controlling the software, and making money. She reinforced the importance of licensing code and discussed the common components of a software license.
      slides (PDF)
    • Relicensing the Montage Image Mosaic Engine, G. Bruce Berriman (Infrared Processing and Analysis Center, Caltech)
      In last year’s Astrophysics Code Sharing session, Bruce had discussed the limitations of the Caltech license under which the code Montage was licensed; since then, Montage has been relicensed to a BSD 3-Clause License. Following on the heels of Laura’s discussion and serving as a case study for institutional concerns regarding software,  Bruce related the reasons for and concerns about the relicensing, and discussed working with the appropriate office at Caltech to bring about this change.
      slides (PDF)
    • Export Controls on Astrophysical Simulation Codes, Daniel Whalen (Institute for Theoretical Astrophysics, University of Heidelberg)
      image of presentation slide

      Restricted algorithms; image by Adam M. Jacobs

      Dan’s presentation covered some of the government issues that arise from research codes, including why certain codes fall under export controls; a primary reason is to prevent the development of nuclear weapons.Dan also brought up how foreign intelligence agencies collect information and what specific simulations are restricted, and stated that Federal rules are changing, but slowly.
      slides (PDF)

    • Why licensing is just the first step, Arfon M. Smith (GitHub Inc.)
      Arfon went beyond licensing in his presentation to discuss open source and open collaborations, and how GitHub delivers on a “theoretical promise of open source.” He shared statistics on the growth of collaborative coding using GitHub, and demonstrated how a collaborative coding process can work and pointed out that through this exposed process, community knowledge is increased and shared. He challenged the audience to contemplate the many reasons for releasing a project and to ask themselves what kind of project they want to create.
      slides (PDF)
    • Licenses in the wild, Daniel Foreman-Mackey (New York University)
      First, I have to note that Dan made it through 41 slides in just over the six minutes allotted for his talk, covering about seven slides/minute; I don’t know whether to be more impressed with his presentation skills or the audience’s information-intake abilities!

      17% of GitHub repositories examined are licensed

      Percentage of licensed GitHub repos; image by Arfon Smith

      After declaring that he knows nothing about licensing, Dan showed us, and how, that he knows plenty about mining data and extracting information from it. From his “random” selection of 1.6 million GitHub repositories, he noted with some glee that 63 languages are more popular on GitHub than IDL is, the number of repositories with licenses have increased since 2012 to 17%, and that only 28,972 of the 1.6 million mentioned the license in the README file. Dan also determined the popularity of various licenses overall and by language and shared that information as well.
      slides (PDF)

Open Discussion
After Dan’s presentation, Alberto Accomazzi opened the floor for discussion. Takeaway points included:

  • Discuss licensing with your institution; it’s likely there is an office/personnel devoted to deal with these issues
  • This office is likely very familiar with issues you bring to it, including who to refer you to when the issues are outside their purview
  • “Friends don’t let friends write their own licenses.” IOW, select an existing license rather than writing your own
  • License your code
  • Let others know how you want your code cited/acknowledged

My thanks to David W. Hogg, Kelle Cruz, Matt Turk, and Peter Teuben for work — which started last March! — on developing the session, to Alberto for his excellent moderating and to Frossie for opening and closing it. My thanks also to the wonderful Jake, Laura, Bruce, Dan W, Arfon, and Dan F-M for presenting at this session, and to the Moore-Sloan Data Science Environment at NYU and AAS for their sponsorship.

Resources
Many resources on licensing, including excellent posts by Jake and Bruce, can be found here.

Software licensing resources

Below, a list of informative, interesting (or both!) writings about software licensing; the ASCL doesn’t necessarily agree with all positions in these articles, but we want to know what people are thinking even when we don’t agree with them.

EUDAT License Wizard
http://www.eudat.eu/news/eudat-license-wizard-guides-you-through-legal-maze
http://ufal.github.io/lindat-license-selector/

A Quick Guide to Software Licensing for the Scientist-Programmer
By Andrew Morin, Jennifer Urban, Piotr Sliz
http://www.ploscompbiol.org/article/info%3Adoi%2F10.1371%2Fjournal.pcbi.1002598

Relicensing yt from GPLv3 to BSD
By Matthew Turk
http://blog.yt-project.org/post/Relicensing.html

Best Practices for Scientific Computing
Greg Wilson, D. A. Aruliah, C. Titus Brown, Neil P. Chue Hong, Matt Davis, Richard T. Guy, Steven H. D. Haddock, Katy Huff, Ian M. Mitchell, Mark Plumbley, Ben Waugh, Ethan P. White, Paul Wilson
http://arxiv.org/abs/1210.0530v4

The Whys and Hows of Licensing Scientific Code
By Jake VanderPlas
http://www.astrobetter.com/the-whys-and-hows-of-licensing-scientific-code/

Licensing your code
ASCL blog post https://ascl.net/wordpress/?p=726 lists the following:

Making Sense of Software Licensing
Choose a license
Open Source Initiative also offers information on licenses
White paper from the Software Freedom Law Center
Bruce Berriman’s post on relicensing Montage

The Gentle Art of Muddying the Licensing Waters
by Glyn Moody
http://blogs.computerworlduk.com/open-enterprise/2014/08/the-gentle-art-of-muddying-the-licensing-waters/index.htm

STM open license suggestions and aftermath

Open Access Licensing
Don’t Muddy the “Open” Waters: SPARC Joins Call for STM Association to Rethink New Licenses
Global Coalition of Access to Research, Science and Education Organizations calls on STM to Withdraw New Model Licenses
STM response to ‘Global Coalition of Access to Research, Science and Education Organisations calls on STM to Withdraw New Model Licenses’
New “open” licenses aren’t so open

Interesting talk on ITAR
http://www.state.gov/e/stas/series/154211.htm
Discusses dual-use technologies, which is what codes are under ITAR. These are governed by the Wassenaar Arrangement. The countries that participate meet 3x/year to decide what restrictions to put on dual-use technologies. Dr. James Harrington was the speaker. Slides available on that page.

Update: Where the codes are; also, a bit about citing software

This is an update on figures I’ve previously shared (most recently here). Currently, the ASCL indexes 977 codes. The percentage of these codes housed on social coding sites are:

GitHub: 8.1%
SourceForge: 4.2%
Code.Google: 2.8%
Bitbucket: 1.3%

This gives us 16.4% of codes listed on the ASCL housed on a public social coding site, an increase since February of 5.4%, most of this from GitHub (up from 4.2% in February), though the percentages of four sites have increased.

As I said in February, I expect the percentage of codes on social coding sites will continue to grow, especially since GitHub’s use is increasing quickly in the community. One factor some credit for this increase is that GitHub has made it easy to push code to Zenodo for archiving and DOI minting, and providing another way to cite code.*

As mentioned in my previous post, how codes are cited vary. Software citation will be the main topic at Tuesday’s inaugural Software Publishing Special Interest Group meeting at AAS225, which will be held at 3:45 PM in 615 of the Convention Center. If you are at AAS this week, you are welcome to attend and I hope to see you there!

 

*It was reported at .Astronomy6 that “some astro journals won’t even accept a DOI as a citation.” I don’t know which journals and hope someone will enlighten me; I would like to know the rationale for that stance and would gladly take this up with publishers.

Astro software citation examples

One of the unconference sessions (proposed during the event) held at December’s .Astronomy was on software citation, this subject having come up in an earlier session on improving credit for software.

Discussion and comments in the session inspired me to look at astronomy’s current practices for citing software. Though not an exhaustive list, I looked in more than a dozen journals for citations for codes used in research, and below are some of the examples I gathered.

The most common way to cite software is to reference a paper describing the code. This is how, for example, the authors of yt would like that software cited, as shown from a recent MNRAS paper:

Other: MNRAS citation for yt
Sometimes a link to the website for a code is listed as a reference to it, as was done in a Classical and Quantum Gravity paper:

Other: URL for CAMB in Classical and Quantum GravityOther: link for CAMB
Conference proceedings are cited in some cases, as the citation below for WCSTools in an The Astrophysical Journal paper demonstrates:

Other: citation from ApJ for conference proceedings for WCStools

ASCL entries can be cited, too, as shown in this citation for pynbody in a paper published in Physical Review D:

ASCL: pynbody citation in PhysRevDSomeone — I don’t remember who — reported that Google Scholar does not index mentions of codes, GitHub repos, etc. as citations, because they are not papers. An opinion tweeted out about this summed up the sentiment in the room pretty well! I plan to take this up with Google after the AAS meeting. Fortunately, ADS does index properly formatted software references; the only reference listed in this post that I didn’t see captured by ADS was the URL for CAMB, which is not surprising (nor expected).

A subsequent post will include additional information and a list of resources about software citation, to be posted before the first Special Interest Group on software publishing meeting scheduled at AAS225 that will be held on Tuesday, January 6, from 3:45 PM – 4:45 PM in 615 in the Convention Center. The main topic of this meeting will be software citation, and all interested parties are welcome to attend.


The journals below were part of my hunting grounds for software citations. Ever had a citation to software you used in research refused by a publication? If so, I’m interested in knowing the details; please share here or send them to editor@ascl.net. Thanks!

American Institute of Physics Proceedings
Astronomy & Astrophysics
Astronomy and Computing
The Astronomical Journal
The Astrophysical Journal
The Astrophysical Journal Supplement
Classical and Quantum Gravity
Icarus
Monthly Notices of the Royal Astronomical Society
Nature
Physical Review D
Proceedings of the SPIE
Publications of the Astronomical Society of Australia
Publications of the Astronomical Society of Japan
Publications of the Astronomical Society of the Pacific

Additional screenshots of software citations:

ASCL: Citation to PyKE in A&AOther: citation for astrometry.net in ApJGasoline citation in PhysRevDScreen Shot 2014-12-28 at 10.18.28 PMScreen Shot 2015-01-01 at 1.54.20 PMScreen Shot 2015-01-01 at 2.04.07 PMScreen Shot 2015-01-01 at 11.35.47 PMScreen Shot 2015-01-01 at 1.40.11 PM

Formatting counts! Below, two citations for Turbospectrum, the first formatted in a way ADS can pick up and count the citation, the second one not.

Screen Shot 2014-12-28 at 10.12.30 PMScreen Shot 2015-01-01 at 1.31.14 PM

Creating and evaluating data management plans

I’m delighted to offer the following guest post by Jonathan Petters, Data Management Consultant, Johns Hopkins Data Management Services, and thank him very much for it!

Funding agencies have long encouraged and expected that data and code used in the course of funded research be made available to those in the research discipline.In a recent discussion on preservation and sharing of research data, a few participants expressed their concern (paraphrased here) that “My research community doesn’t know how to create a quality data management plan” and “We don’t know how to evaluate data management plans.” The astronomy community explicitly requested a little guidance. We in Johns Hopkins University Data Management Services have developed a few resources, described below, of use in both developing and evaluating data management plans within all research disciplines, including astronomy.

Funding agencies have long encouraged and expected that data and code used in the course of funded research be made available to those in the research discipline. NSF is an important funder of astronomical research that has such expectations (and the agency I will focus on here). A few years ago NSF began requiring data management plans as part of research proposal, in part to aid in the dissemination and sharing of research data and code. Following a February 2013 Office of Science and Technology Policy memo other US funding agencies are expected to follow suit with similar data management plan requirements, including the Department of Energy’s Office of Science.

What does NSF say about writing and evaluating quality data management plans? A good overview of NSF data policies relevant for the AST community can be found in these slides from Daniel Katz, NSF). In general the National Science Foundation (NSF) states that data management will be defined by “the communities of interest.” The NSF AST-specific policy further states “MPS Divisions will rely heavily on the merit review process in this initial phase to determine those types of plan that best serve each community and update the information accordingly.” Neither statement is especially prescriptive and can leave researchers unclear as to what they should do.

Creating a plan
While effective research data management certainly has community- and discipline-specific attributes, there ARE aspects of effective data management that are generalizable across research disciplines. It is around these general aspects that we in Johns Hopkins University Data Management Services (JHUDMS) devised our Data Management Planning Questionnaire. We work through this questionnaire with researchers at Johns Hopkins to help them create effective data management plans.

The Questionnaire is designed to comprehensively hit upon the important aspects of effective research data management (e.g. data inputs/outputs in the research, ethical/legal compliance, standards and formats used, intended sharing and preservation, PI restrictions on the use of the data).  By answering the applicable questions in the document, removing the questions/front matter and connecting the answers in each section into paragraphs, a researcher would be well on their way to a quality, well thought-out data management plan.

Two relevant side-notes:
1.)   For the Questionnaire we consider code and software tools as one ‘kind’ of research data; thus analysis or simulation codes used in the course of your proposed research should be included as a Data Product. While research code and research data generated or processed by code are clearly NOT the same, there are many similarities in managing the two. In both cases effective management should include consideration of documentation, licensing, formats, associated metadata, and upon what platform(s) the data or code could be shared.

2.)   Astronomy, as in other disciplines, conducts a substantial amount of research through large collaborations (e.g. surrounding HST or SDSS data). In these cases it is typical for investments in research data infrastructure to be made, and data policies/practices to be defined for those working with the data. Citing those policies and practices in a data management plan would be appropriate.

Screenshot of Reviewer Guide and Worksheet for Data Management Plans

Screenshot of Reviewer Guide and Worksheet for Data Management Plans

Evaluating a plan
To help researchers evaluate data management plans for their quality, my colleagues developed the Reviewer Guide and Worksheet for Data Management Plans (dotx). This Guide and Worksheet is a complement to our Questionnaire; it is a handy checklist by which a grant reviewer can determine whether a researcher thoroughly considered the important aspects of research data management.

For those who researchers saying to themselves, “The Questionnaire and Reviewer Guide are nice, but PLEASE just tell me what to do!!!”, I found two tweets from the code sharing session at the latest (223rd) AAS meeting in January to be quite relevant (h/t August Muench and Lucianne Walkowicz):

Who enforces software/data sharing in astronomy? YOU DO! WE DO! PEER REVIEW DOES! not snf/nasa #aas223 #astroCodeShare It's UP TO YOU to include good data management plan as part of panel reviews. The community must enforce importance. #aas223 #astroCodeShare

I wholeheartedly agree with both tweets. It is up to the research community members to police and enforce the data management and sharing practices they would like to see in their community. That’s how peer review works! So the next time you review astronomical research proposals, look over the data management plans carefully and bring up relevant thoughts and concerns to the review panel.

Summing up
I hope the Data Management Planning Questionnaire and Reviewer Guide and Worksheet for Data Management Plans help you and other researchers in the astronomy community more fully develop expectations for data management and sharing practices. It’s likely your institution also has research data management personnel (like the JHUDMS at Hopkins) who are more than happy to help!

Code citation news, info, and commentary

Mozilla Science Lab, GitHub and Figshare team up to fix the citation of code in academia
The Mozilla Science Lab, GitHub and Figshare – a repository where academics can upload, share and cite their research materials – is starting to tackle the problem. The trio have developed a system so researchers can easily sync their GitHub releases with a Figshare account. It creates a Digital Object Identifier (DOI) automatically, which can then be referenced and checked by other people.

Discussion of the above article on YCombinator
…it always make me cringe when privately held companies want to define an “open standard” for scientific citations that (surprise!) relies completely on their proprietary infrastructure. I still remember the case of Mendeley, which promised to build an open repository for research documents, and which is now a subsidiary of Elsevier, an organization that does not really embrace “open science”, to put it mildly.

Tool developed at CERN makes software citation easier
Researchers working at CERN have developed a tool that allows source code from the popular software development site GitHub to be preserved and cited through the CERN-hosted online repository Zenodo….
Now, people working on software in GitHub will be able to ensure that their code is not only preserved through Zenodo, but is also provided with a unique digital object identifier (DOI), just like an academic paper.

Webcite
WebCite is an on-demand archiving system for webreferences (cited webpages and websites, or other kinds of Internet-accessible digital objects), which can be used by authors, editors, and publishers of scholarly papers and books, to ensure that cited webmaterial will remain available to readers in the future.

DOIs unambiguously and persistently identify published, trustworthy, citable online scholarly literature. Right?
So DOIs unambiguously and persistently identify published, trustworthy, citable online scholarly literature. Right? Wrong.
The examples above are useful because they help elucidate some misconceptions about the DOI itself, the nature of the DOI registration agencies and, in particular issues being raised by new RAs and new DOI allocation models.

Saving software

“…some of the greatest artifacts of the [astronomy] community’s creative problem-solving are at risk of being lost.”

I believe this; a good thing, since this is what Peter Teuben and I wrote in We didn’t see this coming: Our unexpected roles as software archivists and what we learned at Preserving.exe, one of three participant reports in “Preserving.exe: Toward a National Strategy for Software Preservation.”

This report arose from a summit held at the Library of Congress on May 20-21, 2013 by the National Digital Information Infrastructure and Preservation Program. Our piece discusses the summit itself, some of what we learned there, and its impact on the way we think about the ASCL and our work. Among the ideas raised at the summit was that of software as a cultural artifact. We wrote:

The Summit broadened our view and appreciation for software as a cultural artifact and as a method of capturing creativity in problem-solving.

Now we see the loss of computational methods that result in research as a loss of part of astronomy’s cultural heritage. This isn’t happening just for astronomy, of course; the Summit made clear that it is happening for everything. With so much rendered digitally, whether born that way or migrated to a digital medium, without preserving the digital artifacts and the software (and sometimes hardware) to lift these artifacts from their digital storage, we risk losing our art, our music, our games, our prose, our data, and our histories, of daily life and activities, of solutions to scientific problems, of popular pastimes and play experiences, and even knowledge of our computer worries and angst.

More on what we learned at the summit is available in the full report, which includes excellent pieces by participants Henry Lowood, Stanford University (The Lures of Software Preservation) and Matthew Kirschenbaum, University of Maryland (An Executable Past: The Case for a National Software Registry), an introduction by Trevor Owens, Library of Congress, and interviews of Doug White of the National Institute of Standards and Technology’s National Software Reference Library and Michael Mansfield from the Smithsonian American Art Museum.

PreservingEXE: Toward a National Strategy for Software Preservation

Tweets from and about the code sharing session at AAS223

The code sharing crowd took over the AAS Twitter feed, it seems, during the Special Session on code sharing at AAS 223. Bottom up is the best way to read these, as the most recent tweet is on the top, and please note they aren’t strictly in order of occurrence and I likely missed some (there were so many!). I’m happy to add those I missed if someone tells me about them. Thanks to all those who tweeted throughout the session!

  1. ASCL@asclnet 10 Jan
    @
    shaka_lulu
    I keep a list of articles of possible interest to #astroCodeShare folks here: http://asterisk.apod.com/viewtopic.php?f=35&t=21544 …. #aas223
  2. Nuria Lorente@NoTruerAlien 7 Jan
    @
    augustmuench
    @bruceberriman Absolutely, but NOT releasing code also comes at a price, which is often forgotten. #aas223 #astroCodeShare
  3. Zach Pace@zpacefromspace 7 Jan
    Just got finished with an awesome breakout session at #aas223 on code sharing. The moral: your code may be crap, but release it anyway!
  4. Nuria Lorente@NoTruerAlien 7 Jan
    Morin et al: Informative paper on Sw licensing for Scientist-Programmer. MT @augustmuench: http://bit.ly/QlZKDP #astroCodeShare #aas223
  5. Chrissy Madison@cmmadiso 7 Jan
    See. It happens! RT @bathompso: Pulling a @cmmadiso: my phone has 1% battery after the #astroCodeShare session. #AAS223
  6. Ben Thompson@bathompso 7 Jan
    Pulling a @cmmadiso: my phone has 1% battery after the #astroCodeShare session. #AAS223
  7. Adrian Price-Whelan@a_p_w 7 Jan
    RE: writing quick/dirty code to get papers out. “Weeks of programming can save you hours of planning.” #aas223
  8. Lucianne Walkowicz@shaka_lulu 7 Jan
    Hanisch: there should also be a prize for software, esp since Webber prize is for hardware only #aas223 #astroCodeShare
  9. August Muench@augustmuench 7 Jan
    .@AlexaVillaume note: that paper is for software. licensing of *data/papers* is distinct but VERY important thing. #aas223 #astroCodeShare
  10. Lucianne Walkowicz@shaka_lulu 7 Jan
    Licensing: BSD or MIT and forget about it- but we should discuss it more as community – @davidwhogg #astroCodeShare #aas223 cc @jonmccann
  11. Lucianne Walkowicz@shaka_lulu 7 Jan
    @
    jonmccann
    crap I had to answer an email and missed license discussion. Maybe check #astroCodeShare tag if someone else got it
  12. Christopher Hanley@chanley 7 Jan
    @
    eblur27
    Projects should include a citations file in repo right next to LICENCE.txt and README. Make it easier to be cidted #astroCodeShare
  13. August Muench@augustmuench 7 Jan
    so @aaccomazzi brings us back to licensing: unlicenced code is the WORST. @davidwhogg echos this point #aas223 #astroCodeShare
  14. Lia Corrales@eblur27 7 Jan
    Hey #astroCodeShare, I still want to know how I should cite software I get through github. Could help with fluid contributor lists #aas223
  15. Lucianne Walkowicz@shaka_lulu 7 Jan
    Something to be gleaned from size of room v attendance v perceived necessary size of room & how code is valued. #aas223 #astroCodeShare
  16. Ben Cook@bacook17 7 Jan
    Reference in #aas223 code sharing session. http://wssspe.researchcomputing.org.uk
  17. Kelle Cruz@kellecruz 7 Jan
    #
    AAS223
    lots of different ways to share code…but I really want to spend time and energy making it expected & common practice.
  18. Lucianne Walkowicz@shaka_lulu 7 Jan
    Comment in back: u make good science by making good investments- invest in quality code by encouraging code sharing #aas223 #astroCodeShare
  19. Kelle Cruz@kellecruz 7 Jan
    #
    aas223
    I care less about how we data & code share. tech will work itself out. I want to make it a *requirement* for funds and publications.
  20. Alexa Villaume@AlexaVillaume 7 Jan
    A mortifying story of a misplaced 2 in a program causing 8 years of research going down the drain. Share your code. It’ll be ok. #aas223
  21. Meredith Rawls@merrdiff 7 Jan
    .@kellecruz If it’s easy to share code & get credit, we’ll do it. Reminds me of this: http://theoatmeal.com/comics/game_of_thrones … #aas223 #astroCodeShare
  22. Lucianne Walkowicz@shaka_lulu 7 Jan
    There are more ppl in this room than were in the Kepler session I attended yesterday. #aas223 #astroCodeShare
  23. August Muench@augustmuench 7 Jan
    @
    jradavenport
    225: Panel: MMMMMM Q: FMMFFFMM A: all M except 1 comment by F audience #astroCodeShare
  24. August Muench@augustmuench 7 Jan
    So @eteq is gonna drop the mic: papers have fixed author lists. software authorship if fluid and grows. Et tu, ADS? #astroCodeShare #aas223
  25. Lucianne Walkowicz@shaka_lulu 7 Jan
    Reply: if it goes on arXiv you can never update contributor list, so subsequent contributors don’t get credit #aas223 #astroCodeShare
  26. Lucianne Walkowicz@shaka_lulu 7 Jan
    Prsa: would be great if announcement of code went up on arXiv (I think they often do as release papers, e.g. emcee) #aas223 #astroCodeShare
  27. August Muench@augustmuench 7 Jan
    interesting point: Montage built under contract to NASA; astropy built by cats, hosted on a cat based website #astroCodeShare #aas223
  28. Meredith Rawls@merrdiff 7 Jan
    Andrej Prsa implores everyone in #astroCodeShare session to post code on astro-ph every time you submit a paper. #aas223
  29. Meredith Rawls@merrdiff 7 Jan
    My advisor has said not to “waste time” writing generalized code; contradicting this is troubling. Mixed messages. #aas223
    #astroCodeShare
  30. Lucianne Walkowicz@shaka_lulu 7 Jan
    Cost to sharing: making code useable by anyone req more time than just making it work for you then publishing w it #aas223 #astroCodeShare
  31. Meredith Rawls@merrdiff 7 Jan
    Recurring theme of how do I maximize research productivity and make my code useable for others? Not an easy Q. #AAS223 #astroCodeShare
  32. Lucianne Walkowicz@shaka_lulu 7 Jan
    That is, proprietary data sometimes equates to leverage- there is prob some analogy in code community- @davidwhogg #aas223 #astroCodeShare
  33. Lucianne Walkowicz@shaka_lulu 7 Jan
    panelists doubt ppl are being hired for a specific code as opposed to skill, but must be analogy w proprietary data #aas223 #astroCodeShare
  34. Lucianne Walkowicz@shaka_lulu 7 Jan
    Q: how do we reward ppl in ways that don’t req keeping code proprietary? As in, ppl get hired bc they have the code #aas223 #astroCodeShare
  35. Lia Corrales@eblur27 7 Jan
    Sad I’m missing #astroCodeShare, but reports of a packed room and massive twitter coverage are letting me stay comfy in COS session #aas223
  36. Lucianne Walkowicz@shaka_lulu 7 Jan
    Besides, every little thing you think no one else needs- *someone* will prob find it useful #aas223 #astroCodeShare
  37. Lucianne Walkowicz@shaka_lulu 7 Jan
    A: do what you need, if no one else needs it then that’s fine, you haven’t made anyone’s life worse – @davidwhogg #aas223 #astroCodeShare
  38. Lucianne Walkowicz@shaka_lulu 7 Jan
    Q: what’s the balance bt needing to make code work for yourself vs making it useful for everyone always? #aas223 #astroCodeShare
  39. Lucianne Walkowicz@shaka_lulu 7 Jan
    Comment in back: u make good science by making good investments- invest in quality code by encouraging code sharing #aas223 #astroCodeShare
  40. Lucianne Walkowicz@shaka_lulu 7 Jan
    Katz: not really, unlikely beyond a few years’ horizon at a time #aas223 #astroCodeShare
  41. Lucianne Walkowicz@shaka_lulu 7 Jan
    No long term stewardship of code like there is for results (i.e. pubs)- does NSF have plans for that? – @davidwhogg #aas223 #astroCodeShare
  42. Ben Thompson@bathompso 7 Jan
    . @kellecruz starting off the #astroCodeShare question session strong. Why no AAS reps here? #AAS223
  43. Lucianne Walkowicz@shaka_lulu 7 Jan
    Do you use other people’s codes? Do you modify them or use them as is? #astroCodeShare #aas223
  44. Lucianne Walkowicz@shaka_lulu 7 Jan
    Do you share code? If not, why not? #astroCodeShare #aas223
  45. Lucianne Walkowicz@shaka_lulu 7 Jan
    Benefits: perceived priority on work, visibility & good will, citations, bug-catching, and moral high ground – DWH #astroCodeShare #aas223
  46. Alexa Villaume@AlexaVillaume 7 Jan
    Releasing code establishes priority and good will. Benefit from bug catching. Also, you get to be smug. #aas223
  47. Laura Watkins@laurawatkins_ 7 Jan
    @
    davidwhogg
    : if you’re not embarrassed by the code you released, you released it too late. #aas223
  48. Ian Paul Freeley@ianpaulfreeley 7 Jan
    If your not embarrassed by your code/website, you launched too late–Hogg #aas223
  49. Ben Thompson@bathompso 7 Jan
    If you’re not embarrassed by your code, you’re releasing it too late #AAS223 #astroCodeShare
  50. Meredith Rawls@merrdiff 7 Jan
    .@davidwhogg debunks cons to code sharing. Only real cost is email & support requests. He knows of NO example of being scooped. #aas223
  51. August Muench@augustmuench 7 Jan
    hogg: “if you’re not embarrassed by the code/website you put out there then you put it out there too late.” so good. #astroCodeShare #aas223
  52. Lucianne Walkowicz@shaka_lulu 7 Jan
    Cost: embarrassment! You know your code is crap, but if yr not embarrassed you released too late. –@davidwhogg #aas223 #astroCodeShare
  53. Lucianne Walkowicz@shaka_lulu 7 Jan
    Costs: getting scooped? @davidwhogg knows of no cases of scooping caused by *release of code* #astroCodeShare #aas223
  54. Lucianne Walkowicz@shaka_lulu 7 Jan
    All papers, grant writing, etc – not just code – are developed out in the open since 2005. – @davidwhogg #astroCodeShare #aas223
  55. Matthew Turk@powersoffour 7 Jan
    @
    augustmuench
    Not all good or new software is developed using github. Platforms should be transcended by applications. #astroCodeShare
  56. Lucianne Walkowicz@shaka_lulu 7 Jan
    And boom, @davidwhogg right on time. Also, who mic’d him? #astroCodeShare #aas223
  57. Laura Watkins@laurawatkins_ 7 Jan
    +1 MT @augustmuench “and this fact terrifies me because we have no idea collectively what sharing should look like. #astroCodeShare #aas223
  58. August Muench@augustmuench 7 Jan
    and this fact terrifies me because education — we have no idea collectively what sharing should look like. #astroCodeShare #aas223
  59. August Muench@augustmuench 7 Jan
    Who enforces software/data sharing in astronomy? YOU DO! WE DO! PEER REVIEW DOES! not nsf/nasa. #aas223 #astroCodeShare
  60. Lucianne Walkowicz@shaka_lulu 7 Jan
    Its UP TO YOU to include good data management plan as part of panel reviews. The community must enforce importance. #aas223 #astroCodeShare
  61. Lucianne Walkowicz@shaka_lulu 7 Jan
    Data management plans in NSF proposals are required to detail how results/data/software will be shared. – Katz #astroCodeShare #aas223
  62. Lucianne Walkowicz@shaka_lulu 7 Jan
    NSF policy for sharing research results: supposed to share not only the data and the results but the software #astroCodeShare #aas223
  63. Lucianne Walkowicz@shaka_lulu 7 Jan
    NSF does include “products” in addtn to pubs in bio sketches, but could be better abt following up on code release #AAS223 #astroCodeShare
  64. Lucianne Walkowicz@shaka_lulu 7 Jan
    Do we have policies that mandate code release in conjunction w publication or receipt of fed funds? #aas223 #astroCodeShare
  65. August Muench@augustmuench 7 Jan
    Software that enables all this new software: Github, Travis, Sphinx, Jenkins. #aas223 #astroCodeShare
  66. August Muench@augustmuench 7 Jan
    Agreed. RT @kellecruz: .@augustmuench we need to make data/code sharing requirements part of AAS journal policy. those two things. #aas223
  67. Ben Thompson@bathompso 7 Jan
    Testing code is an important part of code sharing. #aas224 session? #AAS223
  68. Kelle Cruz@kellecruz 7 Jan
    .@augustmuench we need to make data/code sharing requirements part of AAS journal policy. those two things. #aas223
  69. Lucianne Walkowicz@shaka_lulu 7 Jan
    If you build it, they will code – Tollerud #aas223 #astroCodeShare
  70. Lucianne Walkowicz@shaka_lulu 7 Jan
    Need infrastructure, a few software ppl to do housekeeping, let scientists do whatev & set expectations – Tollerud #astroCodeShare #aas223
  71. Lucianne Walkowicz@shaka_lulu 7 Jan
    Most ppl who have contributed code to AstroPY have never met each other – all via @github – Tollerud #astroCodeShare #aas223
  72. Ben Thompson@bathompso 7 Jan
    Almost 60 people (who have not met) have all worked together to build @astropy #astroCodeShare #AAS223
  73. Lucianne Walkowicz@shaka_lulu 7 Jan
    AstroPY: a python library for and by astronomers, developed by self-herding astronomers since 2011 – Tollerud #astroCodeShare #aas223
  74. August Muench@augustmuench 7 Jan
    I hoping that we see some cool diffs between the @astropy and montage *support* networks in the open discussion in #astroCodeShare #aas223
  75. August Muench@augustmuench 7 Jan
    . @merrdiff “research objects” is I think the new age terminology. #aas223 #astroCodeShare
  76. David Morrison@drmorr0 7 Jan
    @
    merrdiff
    Best advice I have: learn to use Git (or SVN, if you must), and use it for every single piece of code you write. #astroCodeShare
  77. Lucianne Walkowicz@shaka_lulu 7 Jan
    I have used this exact cat herding graphic in Erik Tollerud’s talk in an LSST talk hehe #aas223 #astroCodeShare
  78. August Muench@augustmuench 7 Jan
    the @astropy project — cat herding software development from @eteq at #astroCodeShare #aas223
  79. Ian Paul Freeley@ianpaulfreeley 7 Jan
    Damn it–tweets from code sharing session sounded cool, but I got here late and now crowd out the door. #aas223
  80. Alex Parker@Alex_Parker 7 Jan
    I’m nodding so vigorously at the #astroCodeShare tweets that I might need to ice my neck later.
  81. Dr Chris Tibbs@chris_tibbs 7 Jan
    Love the fact that my timeline is currently full of great tweets about code sharing and EPO #aas223
  82. Kelle Cruz@kellecruz 7 Jan
    #
    aas223
    ok, maybe 20% women in code sharing session but still disproportionately tweeting. #interesting
  83. Alexa Villaume@AlexaVillaume 7 Jan
    “I wrote my first fortran code when Apollo 12 was on the moon.” #aas223
  84. August Muench@augustmuench 7 Jan
    Decision to code Cloudy in C++ was partly motivated to use industry grade lang & give students real world job ops! #astroCodeShare #aas223
  85. Meredith Rawls@merrdiff 7 Jan
    Learning about the CLOUDY code, but speaker has no visuals 🙁 Jokes that the code can be opaque; “C++: write once, read never.” #aas223
  86. Lucianne Walkowicz@shaka_lulu 7 Jan
    Complaining astros aren’t comp scientists is like saying they shldn’t learn math bc they aren’t mathematicians #astroCodeShare #aas223
  87. Timothy Pickering@te_pickering 7 Jan
    #
    preach
    ! RT @shaka_lulu: I’ll paraphrase @mjuric here: code is to modern astronomy what calculus once was. #aas223 #astroCodeShare
  88. Lucianne Walkowicz@shaka_lulu 7 Jan
    I’ll paraphrase @mjuric here: code is to modern astronomy what calculus once was. #aas223 #astroCodeShare
  89. Kelle Cruz@kellecruz 7 Jan
    #
    aas223
    could someone in the back of the code sharing session do a quick attendance & gender count? I’m in the front row…
  90. Jessica Lu@jlu_astro 7 Jan
    @
    kellecruz
    Tell me if you figure it out!
  91. Kelle Cruz@kellecruz 7 Jan
    #
    aas223
    code sharing room is packed! I’m curious what brought them all here…
  92. Lucianne Walkowicz@shaka_lulu 7 Jan
    Q: how much do you think we fail to educate our young researchers to write good code? #astroCodeShare #aas223
  93. Ben Thompson@bathompso 7 Jan
    Q on why students are not educated on how to write good code (or code at all!) #AAS223
    We have all failed here.
  94. August Muench@augustmuench 7 Jan
    The code base under question is Montage http://bit.ly/1aELvEz , dev’d & now volunteerly supported by IPAC scientists #aas223 #astroCodeShare
  95. August Muench@augustmuench 7 Jan
    “Releasing your code comes with a price” — @bruceberriman Hmm, let’s see if this pivots to the positive+solutions! #aas223 #astroCodeShare
  96. Lucianne Walkowicz@shaka_lulu 7 Jan
    Lastly, resist the pundit-technician divide. – Weiner #aas223 #astroCodeShare
  97. August Muench@augustmuench 7 Jan
    I completely agree with @cloud149: a lot of our concerns about sharing code are “pseudo” or hypothetical problems. #aas223 #astroCodeShare
  98. Michelle Collins@michelle_lmc 7 Jan
    We are failing to teach students how to write GOOD code in astronomy. Need to do better. Some programs in place, but not standard #aas223
  99. Laura Watkins@laurawatkins_ 7 Jan
    “Do we do enough to teach our researchers how to write good code?” No. Fundamental skills but so many are left to learn alone. #aas223
  100. Kelle Cruz@kellecruz 7 Jan
    #
    aas223
    really interesting that nearly 100% of the women in the code sharing session are tweeting…all 4 of us. #exaggerating
  101. Laura Watkins@laurawatkins_ 7 Jan
    Standing room only at the code sharing session. Apparently this is more popular than anticipated (this can only be a good thing)! #aas223
  102. Meredith Rawls@merrdiff 7 Jan
    Astrophysics code sharing session 225 at #aas223. Let’s stop re-inventing the wheel. Our hardware is built to last; why not software?
  103. Michelle Collins@michelle_lmc 7 Jan
    Oh, there are no women on the code sharing panel. Are we not sharing code? I’m currently not, but i’m here to learn how to #aas223
  104. Ben Thompson@bathompso 7 Jan
    Excited for the Astronomy Code Sharing session. Wondering what to do with all my research programs. #AAS223
  105. Erik Tollerud@eteq 7 Jan
    #
    aas223
    , Tues@2pm: talking about lesson’s from @astropy on how code can be shared, along side @owlice @davidwhogg @bruceberriman @cloud149
  106. Benjamin Weiner@cloud149 7 Jan
    My talk “Occupy Hard Drives” for code session Tues 2 pm #aas223 is here: http://bit.ly/1acClmg @davidwhogg @bruceberriman @owlice @eteq
  107. ADASS@astroADASS 7 Jan
    Follow discussion on astronomy code sharing at the #aas223 meeting using #astroCodeShare hashtag.
  108. Benjamin Weiner@cloud149 7 Jan
    Tues 2pm #aas223 I aim to provoke on astro code sharing and why we don’t respect software with @davidwhogg @bruceberriman @owlice @eteq
  109. Astropy@astropy 6 Jan
    At the #aas223? Don’t miss Tuesday’s 14:00-15:30 session on code sharing – including a talk by @eteq about @astropy!

  110. David W. Hogg@davidwhogg 6 Jan
    Tues at 2 see @owlice Hanisch Teuben @cloud149 @bruceberriman Ferland Katz @eteq and me get all crazy about #code sharing at #aas223 in NH5