Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make list of maintainers for application definitions #1254

Closed
phyy-nx opened this issue Apr 21, 2023 · 7 comments · Fixed by #1299
Closed

Make list of maintainers for application definitions #1254

phyy-nx opened this issue Apr 21, 2023 · 7 comments · Fixed by #1299
Assignees

Comments

@phyy-nx
Copy link
Contributor

phyy-nx commented Apr 21, 2023

One of the ideas that came out of the April 2023 telco (minutes), during discussion of #1011, was that it would be a good idea to add "maintainers" to application definitions. These would be people who are most interested in guiding the maintenance and development of a given definition, or have an interest in it as a community member, or were long time contributors to it and can guide new users in its use or answer questions. Critically, they wouldn't need to be NIAC members.

I'm happy to set this up, my question is, where should it live?

Proposals:

  1. Add lists of application definitions to NIAC members on the NIAC web page.
  2. Add contact information (github handles?) to the list of application definitions
  3. Add contact information (github handles?) to individual definitions. Perhaps in the the form of a new attribute or field? Or in the doc string?

Or some combination of the above. Thoughts on this? Thanks!

@zjttoefs
Copy link
Contributor

I'm opposed to that idea.

  • The interest of people often follows their facility lifecycle. But taking over someone's baby will always be seen as somewhat hostile, even if that baby has been a little neglected.
  • What would being a "maintainer" mean in practice? Can you make changes without review by NIAC?
  • In practice you can check the gitlogs to see who has been editing a file last, if you need a second opinion on something.

@rayosborn
Copy link
Contributor

@zjttoefs, it's possible that "maintainer" is the wrong word, but I think it is essential that there is a point-of-contact for each active application definition, one who is aware of its history and current status and can respond to questions. There are several ADs that were thrown together a long time ago (I'm sure I contributed to at least one) but have never been properly validated by the community and sometimes never used. However, a newcomer would assume that use of this definition is mandatory, even if it is inadequate to their needs. It is like coming across a PyPI package that hasn't been updated in ten years or more, whose original author is unreachable. Would you use it?

@phyy-nx
Copy link
Contributor Author

phyy-nx commented Apr 24, 2023

I can see nervousness around scope here and I agree I'm not quite sold on the word maintainer. "Helpful explainer" is more the vibe I was going for. But one additional point for @zjttoefs is that for probably most users of NeXus not related to this committee, the github page for eg NXmx, which has 11 contributors, is completely hidden compared to the manual page, which has no point of contact listed.

@prjemian
Copy link
Contributor

prjemian commented Apr 24, 2023 via email

@phyy-nx
Copy link
Contributor Author

phyy-nx commented Jun 15, 2023

Compromises discussed in Code Camp: take advantage of the side bar space on the right hand of the page and add one or more of the following under the "This Page" heading:

image

Thoughts?

@prjemian
Copy link
Contributor

side bar space on the right hand of the page

Which page? Can you give an example?

@phyy-nx
Copy link
Contributor Author

phyy-nx commented Jun 15, 2023

Ya, here's a screenshot of where I mean:

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

5 participants