OpenAstronomy

Google Summer of Code, open proposals and claims of plagiarism

Mon, 01 Jun 2026 00:00:00 +0000

This is our 10th anniversary participating in GSoC as Open Astronomy, and a few more years for us, the org-admins, who have been taking part under the Python Software Foundation umbrella before OA was formed.

This year was the first one we’ve enforced the open proposal system for all the sub-organisations involved under our umbrella. We did it as a mechanism to avoid LLM slop and to make it as transparent as possible for all the participants, after all, SunPy had been using this approach since 2013 without any problems.

This time, however, after the selections were announced we got a message from GSoC admins about a complaint involving plagiarism between proposals. We’ve spent a whole week analysing the situation involving all of the three OA organisation admins, the lead mentor of the project involved, and GSoC admins. Below, we detail some lessons learnt about this situation to help avoid this happening in the future.

Inspiration or plagiarism. Using an open proposal approach (and mostly now in the age of LLMs), it’s not surprising to find that people may get inspiration from others when trying to propose a solution to a problem. And, that’s OK! What’s however unethical is to not attribute where the idea comes from, whether from discussing with mentors, from a chat with others, or cooked up by an LLM. As an organisation that is based on Research Software that supports researchers, this is a serious issue. This will be clearly highlighted on our template for future editions.
Evaluation. The evaluation of the candidates never have been solely based on the proposals. In fact, the proposal document itself is the least important part of the application. We need that to document the work plan and your background and availability but nothing more. After all the details of the work, in the ideal case, is the result of a collaboration with mentors and other contributors of the hosting project. We’ve got that as the first point of our guidelines: The better we know you, the better we can judge your application. This means that besides having a good proposal and demonstrating its understanding (through an interview), everything such as: How the candidates interact with the community, answer to feedback, welcome and help other candidates to get started, and much more, counts! GSoC is not a competition or an internship/job, GSoC is a programme to build community and develop future maintainers. This is already mentioned in our guidelines, but we will make sure it is more specific.
Gaming the system? This year was the first time we used github pull requests as a method to publish the proposals openly. And for the first time, we found multiple interpretations to the rules we set. From opening an empty pull-request before the deadline and not sharing the content until just after, to uploading all the proposals in a single commit. There were also cases of using pdf rather than md files or grouping multiple proposals in a single pull-request. The other purpose of open proposals, is to follow the open development approach that is followed by our organisations (second point of our principles). As with software, the candidates are expected to work in the open, show the evolution of their proposals in multiple commits and iterating on their draft as it gets to a complete status. Ideally, even with time enough to get feedback from the community (not just the mentors). This also helps to show who comes with original approaches and avoids having to find out whether some ideas were shared before on different channels. This time, we are going to assume that the purpose and instructions weren’t made clear, but it won’t be the case in future editions. Single commit applications will be ignored, at the deadline all the PRs will be merged and no further modifications will be considered, and applications that do not use the template format will be excluded.

2019 Jul 29 - Aug 2 - Python in Astronomy

Mon, 29 Jul 2019 00:00:00 +0000

The Python in Astronomy conference will be held at the Space Telescope Science Institute in Baltimore during July 29th - August 2nd. Check out the conference website for more information.

2018 September 24-27 - .Astronomy X

Mon, 24 Sep 2018 00:00:00 +0000

The tenth .Astronomy meeting will take place in Baltimore MD from September 24-27, 2018.

2018 August 14: GSoC - End of Coding

Tue, 14 Aug 2018 00:00:00 +0000

Students submit their final work product and their final mentor evaluation.

First OpenAstronomy - Software Carpentry Workshop

Fri, 15 Jan 2016 00:00:00 +0000

Last week (11-15th January 2016) saw the first Open Astronomy workshop held at The University of Sheffield for the UK astronomy and solar physics communities. The first two days of the workshop consisted of the core syllabus of Software Carpentry, covering git, bash and an introduction to programming with Python. The last three days provided an introduction to carrying out research in astronomy using Python. The attendees were mostly PhD students in Astrophysics from the University of Sheffield, however there were also representation of other fields (mathematics, medicine, ecology), from other universities (St. Andrews, Reading) and at different stages in their careers (post-docs).

The workshop was taught by four different instructors (Sam, Drew, Stuart and David) with the help of Tom (an Astropy developer) on Thursday. We all brought different expertise and shared the teaching out to keep the workshop lively over a gruelling five days none of us taught more than three hours in one go, and we alternated days between teaching and assisting. We used the red-green post-it technique suggested by software carpentry as a way to know how people were getting on during the sessions, also, for every session the learners were asked to use these post-it notes to give us feedback on the session (green for something good you’ve learnt, red for something that can be improved). This not just helped us for the next workshop, but it also helped to the next instructor that day!

As usual there were some software setup issues at the beginning of the week, however we were very close! Only one person from the whole class has troubles with the Jupyter notebook - it simply was not able to execute any command within. We didn’t manage to fix the problem, but probably it was the oldest laptop (running Windows 7) in the class. Beside that case, we come across a couple of other problems with other windows machines, in one of them git log was blocking the screen and the other could not open the text editor (Notepad++ in this case) when executing commit (or merge with the default message).

Each day we updated the official repository with lesson templates in Jupyter notebook format, where an outline of the class was available, and the code cells were empty to be filled in while following the lecture. Once we completed a session, the notes can be browsed here. In this way everyone had to fork our repository on github, then pull at the start of every session from upstream and push at the end to their origin. This cemented the work at the start of the week on git+GitHub, while making sure everyone had a backup of all the work they had completed during the week and learning the usual git workflow of contributing to a larger project on GitHub. Thanks to the visualisations on GitHub we can see how all these forks evolved, and see if the participants keep using GitHub!!

During one of the sessions we discovered a bug in the latest release of SunPy. We used the opportunity to demonstrate what to do in these cases: fill an issue on GitHub and provide the information needed so the developers can replicate such error.

We will be looking to repeat this workshop later in the year, probably before term starts in late September. In the mean time, feel free to use our material and contact us if you want more information.