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

Document who is maintaining each component #121

Open
ctrueden opened this Issue Apr 20, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@ctrueden
Member

ctrueden commented Apr 20, 2015

The documentation needs to be clearer about who is formally responsible for maintaining each component of the SciJava software stack. I would like to differentiate between "active" and "minimal" maintenance, similar to how Drupal does it. Having a formal pledge from each maintainer, along with a list of responsibilities entailed by that pledge, posted publicly on the wiki, will make Fiji and the entire SciJava software stack stronger.

@tinevez

This comment has been minimized.

Show comment
Hide comment
@tinevez

tinevez Apr 20, 2015

Member

There was once a wiki page dedicated to find plugins without maintainer:
http://fiji.sc/Template:BlamePage
It was generated from a python script that was crawling a Fiji installation, fetching corresponding info from the wiki and checking what plugins did not declare a maintainer,
@ctrueden you have something like this in mind?

Member

tinevez commented Apr 20, 2015

There was once a wiki page dedicated to find plugins without maintainer:
http://fiji.sc/Template:BlamePage
It was generated from a python script that was crawling a Fiji installation, fetching corresponding info from the wiki and checking what plugins did not declare a maintainer,
@ctrueden you have something like this in mind?

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Apr 20, 2015

Member

@tinevez Something like that, but much more clear. Again, see how Drupal does it, which I really like. They differentiate between "minimal" maintenance—which means PR will be reviewed & merged, but the maintainer(s) do not have time to actively fix bugs or add features—and "active" maintenance, which implies the project is under active development in some fashion.

The metadata should live in each project's pom.xml in the <roles> section of <developers>, with the roles defined precisely and consistently on the wiki somewhere. Then we can code generate any wiki pages which enumerate the components, and keep them up to date using scripts via Jenkins.

The ultimate goal is to better manage community expectations; i.e., to help answer questions such as:

  • Who answers questions about each particular component?
  • What happens if I file an issue? Will it get worked on? When? Under what conditions will it be closed?
  • What happens if I file a PR? Will it get merged? By whom? When?
  • Is this project still active? What is planned for its future?

See also Fiji contribution guidelines for related issues.

Member

ctrueden commented Apr 20, 2015

@tinevez Something like that, but much more clear. Again, see how Drupal does it, which I really like. They differentiate between "minimal" maintenance—which means PR will be reviewed & merged, but the maintainer(s) do not have time to actively fix bugs or add features—and "active" maintenance, which implies the project is under active development in some fashion.

The metadata should live in each project's pom.xml in the <roles> section of <developers>, with the roles defined precisely and consistently on the wiki somewhere. Then we can code generate any wiki pages which enumerate the components, and keep them up to date using scripts via Jenkins.

The ultimate goal is to better manage community expectations; i.e., to help answer questions such as:

  • Who answers questions about each particular component?
  • What happens if I file an issue? Will it get worked on? When? Under what conditions will it be closed?
  • What happens if I file a PR? Will it get merged? By whom? When?
  • Is this project still active? What is planned for its future?

See also Fiji contribution guidelines for related issues.

@hinerm

This comment has been minimized.

Show comment
Hide comment
@hinerm

hinerm Apr 24, 2015

Member

See also Fiji contribution guidelines for related issues.

As part of this, I think the contribution guidelines should be updated to explain these expectations (e.g. developers should have a wiki page for their plugin to document these things)..

Member

hinerm commented Apr 24, 2015

See also Fiji contribution guidelines for related issues.

As part of this, I think the contribution guidelines should be updated to explain these expectations (e.g. developers should have a wiki page for their plugin to document these things)..

@ctrueden ctrueden added this to the m2 milestone Jul 29, 2015

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden May 11, 2017

Member

Over two years later, I am finally on the cusp of completing this project. See this forum thread and the scijava/mediawiki-maven-info repository. Together with the grand pom-scijava unification and corresponding update of project metadata, and new status.scijava.org site, we are nearly ready to turn on a CI job which will auto-update MediaWiki templates for all components, such that their sidebars become fully autogenerated from their respective POMs. Whew! 😌

Member

ctrueden commented May 11, 2017

Over two years later, I am finally on the cusp of completing this project. See this forum thread and the scijava/mediawiki-maven-info repository. Together with the grand pom-scijava unification and corresponding update of project metadata, and new status.scijava.org site, we are nearly ready to turn on a CI job which will auto-update MediaWiki templates for all components, such that their sidebars become fully autogenerated from their respective POMs. Whew! 😌

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Jun 5, 2017

Member

I regenerated all the sidebars based on imagej-2.0.0-rc-61 and fiji-pre-1. And I updated the vast majority of the corresponding ImageJ wiki pages to use ComponentStats sidebar templates.

The current way that the mediawiki-maven-info code works is rather defective, though, and still needs another iteration of development before we will be able to fully automate updates. For the moment, it will be most realistic to simply document the process which needs to be performed manually to update things.

Member

ctrueden commented Jun 5, 2017

I regenerated all the sidebars based on imagej-2.0.0-rc-61 and fiji-pre-1. And I updated the vast majority of the corresponding ImageJ wiki pages to use ComponentStats sidebar templates.

The current way that the mediawiki-maven-info code works is rather defective, though, and still needs another iteration of development before we will be able to fully automate updates. For the moment, it will be most realistic to simply document the process which needs to be performed manually to update things.

@imagejan imagejan referenced this issue Jan 11, 2018

Open

Retire jenkins.imagej.net #178

10 of 20 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment