The Orekit project maintainers are committed to the best practices of free and open source software. They try to create the technical environment and climate of trust necessary for the emergence of a community and its smooth running.
It seems to me that they are succeeding rather well, given the vitality of the project, the number of exchanges on the forum and the involvement of a growing number of people in Orekit (each contributing at his or her own level, according to skills and availability).
This doesn’t prevent us from looking at what other projects are doing, comparing experiences and adopting good ideas and new best practices. With this in mind, I’d like to refer you to a lecture given this summer by the creators of the F3D project. The talk is (unfortunately for many of you) in French, but the slides are in English.
Depending on one’s sensibility, one may or may not agree with the actions and practices listed.
A regular release rhythm (this avoids the tunnel effect I sometimes see between two releases, during which the community doesn’t really know what’s going on).
Announcement of a roadmap (which doesn’t commit to anything, since everyone does what they can according to their availability, but which gives the community an idea of future developments). An embryonic roadmap exists within the Orekit project, by associating tickets with milestones.
Improving the issues published by users, to provide as much information as possible, and to enable inexperienced or new contributors to grasp and process them.
Formalize a workflow (Git). If I am not mistaken, no workflow has been formalized for the Orekit project. While many contributors push their modifications on working branches, some push their contributions directly on the develop branch. Are this and other practices desirable? If you don’t think so, perhaps you need to define a (sustainable and consensus-based) Git workflow.
Finding media to communicate on, such as Reddit.
And here’s what I find less interesting, given Orekit’s ecosystem as it exists today:
Use of Discord. Discord has many fans, but Discord is an instant messenger. A forum, such as the one used by the Orekit community, has the advantage of structuring exchanges into categories and topics, and of making these exchanges indexable by search engines (external engines or the built-in one). In my opinion, a chat can complement a forum, to enable team coordination, but it should not replace the forum. If both exist, there’s a risk that the chat will siphon off the forum’s exchanges and that the community will lose the memory of these exchanges and the ability to discover them.
I would really much like us get a code of conduct. It may seem irrelevant as we have not faced wrong behavior issues yet, but we should have one before it happens.
We do have a workflow : git flow and it is explained in the guidelines. We sometimes don’t follow it (and I am probably the one who fails to do this the most).
I also prefer a forum to a direct messaging system. Our current forum works well and people seem to find it useful. We also see sometimes older thread being revisited, which means preserving history meets users expectations.
We are lacking momentum for releases, it is an old problem and I’m afraid it will remain this way until we have tens or hundreds of committers. I am still quite happy with what we achieved with our limited workforce.
I remember my n+2 manager stating definitely that there was no such thing as a space flight dynamics community more than 25 years ago (those who know me will deduce who it was); the healthy Orekit community proved him to be completely wrong.
It is necessary and we shall move foreward this topic!
I completly agree and I think that we shall imporve on this topic. To my mind, it is the most important topic we should improve.
The first thing to do is to accept that a release with 5-6 new features and 2-3 bug corrections is completly acceptable. However, it seems that Orekit developers (me included) apprecitate having releases with 50 fixed issues or even 200 as for the 12.0 or 115 as for the 12.1. We are far from respecting the “Release Early, Release Often” mantra. I really think that having “extra monster big” releases like 12.0 or 12.1 is not acceptable. First of all because with 115 issues like 12.1 we can do 3 or 4 minor releases. In addition, upgrading its Orekit version between two releases with tens or hundreds of issues is really difficult. I remember that upgrading from 11.X to 12.X was a very important challenge (even for an Orekit developer).
Having a regular release rythm in terms of time is difficult because the most part of the developments are now done on the free time of the developers and contributors.
An easy-to-do alternative could be to stop the developments after N fixed issues (e.g., 15 or 20 fixed issues) and to release as it.
On this last point, we didn’t understand each other. Reddit is not a tool for internal communication (i.e. exchange within the community), but for external communication (reserved, for example, for announcing releases, or for spotlighting major developments and creating some buzz).
It’s not easy for me to imagine a dedicated Orekit page on Reddit, probably because I spend my time posting “funny” memes on it. But, yes that’s a popular application with different targets so it could be interesting to have a r/Orekit
For extrernal communications, some of them use LinkedIn.
I agree with all that has been said so far, thank you @sdinot for sharing the slides, the F3D project itself looks very interesting.
Another option would be to fix the dates of the releases. We decide as a community that there will be 3 or 4 minor/major releases per year and we date the milestones.
Once the date is due, the unfinished issues are moved to the next milestone.
Of course, if someone needs a week or so to finish an issue that he or she really needs to see in the next release, we can decide to delay a little.
We don’t need to be adamant about these milestones but at least it provides a target that we’ll be trying to reach.
What would you think of that kind of process?
I personally like the idea of seasonal releases (21th of march for the spring release and so on), we’re an astrodynamics library after all
To me this is also the main topic to improve and i like @MaximeJ suggestion to do seasonal or at least planned release dates without being too adamant about it.
Maybe we could make a poll about that on the forum to see if people are interested ? Maybe even include discord (even though i would find it unlikely to be selected for good reasons) ?
If you propose to use Discord, be firm on two points:
It would be a tool for synchronous exchange between developers, not a means of assistance or bug reporting. Discord can be useful, for example, for organizing progress reviews and coordination meetings. But this should be its only use.
Requests for help, which are handled asynchronously depending on people’s availability, and substantive topics, which are of interest to the whole community, should be discussed on the forum. Issues and enhancement requests should be reported to the GitLab bug tracking system.
But given the way you currently operate and the tools already available to the community, given that many contributors work on Orekit in their spare time, and given that these contributors are spread across different parts of the planet, I’m not sure Discord is a tool to propose to the community.
Code of Conduct - very important, anything is better than nothing here.
On forums… I really find this forum useful and a useful recommendation as go-to place for new users, and the know-how I think should as stated stay here. Discord, yes maybe could be useful in release process and some coordination, not a big need from my side but could be useful.
Not sure I get the point of a code of conduct. Give justifications to ban misbehaving users?
I think the forum in its current form is good, it enables to look for questions posted in the past (so a good input for generative AI) and if nothing matches, ask it. Maybe we could benefit from a “welcoming thread” where new users can properly introduce themselves before the technical stuff. This would also help us understand who uses Orekit and how, because for me it’s still unclear. Some actors are clearly identified, for example in the Project Management Committee, but surely this is just the tip of the iceberg.
As for the releases, I wouldn’t be against a calendar or at least a given pace, say 2-3 minor and one major a year. But let’s bear in mind that this is only possible if we have reccurrent, not-so-small contributions. I think we should also reconsider the on-hold idea of upgrading to modern Java. This could help us attract both more contributors and users.
Last but not least, Orekit talks? It’s sad to see there’s not been any in a while. I think they attracted a sizable audience.
The code of conduct (CoC) is both an expression of the community’s intentions (on the fundamental values shared by its members), and of the behaviors and statements that are not acceptable within the Orekit project.
To this day, I can’t recall a single attitude or statement made by any member of our small community that would have merited the slightest call to order. On the contrary, I’m constantly reminded of how impressed and respectful I am of the climate in this community and the attitude of its members. I’d like all open source projects to offer the same experience to those who venture into them.
If a toxic person ever interferes in the project, you can let him or her know that his or her insulting remarks or outrageous attitude are not welcome, that he or she should refrain from doing so again, and even that an apology to those voluntarily offended would be desirable. But this person may reply that you’re expressing a personal sensitivity and that you can keep it to yourself. It will be one person’s opinion against another’s. And even if you win in the end, that person will say they’ve been the victim of a cabal.
With a CoC, the assessment of the situation is clearer and more objective, since the CoC represents the values shared by the community, a common reference.
The CoC must exist before the problem occurs. If it comes later, it’s just a band-aid for a painful episode. I’ve known projects that exploded before…
It would be really cool to revive these presentations on Orekit’s functions and uses. We could also launch interviews with users and contributors: “Hi, who are you? What can you tell us about yourself? What are you doing with Orekit? Do you contribute to the project?”
It would be really cool to revive these presentations on Orekit’s functions and uses. We could also launch interviews with users and contributors: “Hi, who are you? What can you tell us about yourself? What are you doing with Orekit? Do you contribute to the project?”