Doing open source

[jpivarski]

Time management, delegation strategies, and governance models for package managers; how to break in and what to expect for newcomers to open source development. Interaction between physics collaborations and collaboration-agnostic tools.

[amangoel185]

Would be interested in this.

Curious if this could also entail career paths and developer health - how to incentivise people to contribute? Also DEI, how do we make open source more accessible & equitable?

[sudo-panda]

+1

[mattbellis]

+1 Very interested in this discussion!

[klieret]

I am very interested in this.

I'm not completely sure in which group this fits -- or if it is interesting enough to have a separate side chat), but I am particularly interested in how collaborative development for ML R & D projects is done best. This comes with a series of unique challenges (while other problems of developers, like backwards compatibility, are somewhat less important because everyone is a developer).

Edit: Moved to new issue #26 .

[matthewfeickert]

Time management, delegation strategies, and governance models for package managers

I'm interested in this with a focus on learning how to make it easier for new contributors to get onboarded (This is said looking towards the 2023 pyhf Users and Developers Workshop).

Interaction between physics collaborations and collaboration-agnostic tools.

I'm also interested in how to communicate that if experiments use open source tools and want new features on a timeline that the experiments should be willing to contribute to the project.

[clelange]

I'd also be interested in finding ways to actually getting more collaborators to contribute to open source projects maintained by their peers. I see very few people from our community even creating issues...

[matthewfeickert]

I see very few people from our community even creating issues

Agreed. I understand why for pyhf people on ATLAS will sometimes email the pyhf devs to ask for help as they have ATLAS internal workspaces, but even then we ask them to see if they can abstract away the issue that they're having and publicly post it on GitHub and just mention that there is a private workspace associated with it. In general though I would agree that there are some groups of people on LHC experiments that seem to feel for whatever reason that they shouldn't/can't/don't want to contribute to the open source projects they use. I say this not to blame them at all, but it would be useful to better understand why that is the case and if we can lower/remove any barriers towards their contributions.

[mattbellis]

@matthewfeickert Not sure if you've seen this, but I worked on a white paper for Snowmass, "Climate of the field"

https://arxiv.org/abs/2204.03713

Section 6, " Equity in information sharing / HEPA software" is what I focused on and we shared some anecdotes about how the HEPA software experience can be intimidating, even though it is not intended, in part because of community practices. I'd be happy to chat about this this week as I believe it is overlooked.

To first order, I think it would be great to organize a "Women and Gender-minorities in scientific software" workshop (feel free to suggest a better name). or "W&Gm in HEP software" or "W&Gm in PyHEP" if you want to limit the scope. I'm sure I (and many others) have blind spots that we are not aware of and so it would be good to gather the users in a common space to hear their perspectives and experiences.

[Moelf]

+1 I think physicists are pretty good coders but too often the code base is they need/want to contribute to is too far from what they're familiar with from even extensive usage.

and sometimes projects have pretty high barrier of entry (sometimes physics software host somewhere or doesn't collaborate in the open, or for example Google wants you to sign some forms before and code can be merged)