community-supported module resources

classic Classic list List threaded Threaded
9 messages Options
Jeremy Keiper-3 Jeremy Keiper-3
Reply | Threaded
Open this post in threaded view
|

community-supported module resources

All -

We (Michael, Ben and Jeremy) have a brewing debate that we would like to open up to the community for resolution.  The concern is about providing project-specific ticketing mechanisms for unsupported (or sporadically community-maintained) modules.  It began when a contributor accidentally worked on a core patch for TRUNK-1815 when the patch was needed on the Form2Program Module.  Below is the current dialog.  Please contribute and help us resolve it before we all lose what hair we have left.  Thanks!

[Michael Downey]

The maintainer of the Form2Program module should be made aware of the issue and this issue either closed/cancelled or moved to a project if that person wants one in JIRA.

[Ben Wolfe]

The "maintainer" is the general community since the original author is
gone. I assume there will not be many bugs/issues with this module, perhaps
only this one. How about that general module project now Michael?   How
many more examples do I need to find before you make one?

[Michael Downey]

If we are going to have modules that are no longer actively maintained (like this and others), we need a way to mark modules as "unsupported" in the Module Repository until AMO or the equivalent is ready. After all, as Ben said himself in the disclaimer of the modrepo home page, "OpenMRS is providing links to these modules as a courtesy, and makes no representations regarding the modules or any information related there to. Any questions, complaints or claims regarding the modules must be directed to the appropriate module vendor." If we want to change that policy, that is something that can be debated, but it should be done publicly and consensus reached about a major change in approach.

A paradigm where add-on modules that are solely "community-supported" with no responsible named party or point of contact may have worked for a smaller project, but it neither feasible nor sustainable for a worldwide growing ecosystem.

What about adding '[Unsupported]' to orphaned modules or those that are no longer being actively maintained? When AMO (or similar) goes online we could mark them more clearly.

[Ben Wolfe]

Why must you dance around the issue? And why are we having this discussion
on this ticket?

The issue at hand: We need to put this ticket someplace. It does not belong
in TRUNK, it does not belong in its own project (yet). Where to put it?

[Michael Downey]

As I suggested above, this and all issues for modules belong in the possession of the maintainer of that module in whatever form (e.g., JIRA or other issue tracker, email, post-it note, text file, etc.) that person chooses for support of that module. For unsupported modules, the ticket should be cancelled/closed and marked as non-supported.

Put more succinctly: For this specific module, either (a) an individual can volunteer to become responsible for its care-taking, and subsequently consider working on the issue reported here, or (b) it should be retired and marked as such somehow, and this should ticket be cancelled as a result.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: community-supported module resources

There's great strength in keeping modules (their documentation, code, and tickets) under the OpenMRS umbrella, because:
  • it allows devs to easily step in and contribute code to a module
  • it allows users to easily go to one place for support and bugs, even with different module "vendors"
  • it allows module ownership to transition between people over time
That last point is particularly important. The form2program module used to be owned by Brian. Now it's owned by "nobody" (but I'd rather phrase that, like Ben does, as "the general OpenMRS community"). Maybe in the future some individual will pick it up. Maybe an organization will build an OpenMRS distribution that bundles that module, and take some ownership. But there's no need to mark all its tickets as "denied" as long as they don't have an owner.

(+1000 for a "random modules" jira project)

-Darius

On Tue, Mar 8, 2011 at 2:41 PM, Jeremy Keiper <[hidden email]> wrote:
All -

We (Michael, Ben and Jeremy) have a brewing debate that we would like to open up to the community for resolution.  The concern is about providing project-specific ticketing mechanisms for unsupported (or sporadically community-maintained) modules.  It began when a contributor accidentally worked on a core patch for TRUNK-1815 when the patch was needed on the Form2Program Module.  Below is the current dialog.  Please contribute and help us resolve it before we all lose what hair we have left.  Thanks!

[Michael Downey]

The maintainer of the Form2Program module should be made aware of the issue and this issue either closed/cancelled or moved to a project if that person wants one in JIRA.

[Ben Wolfe]

The "maintainer" is the general community since the original author is
gone. I assume there will not be many bugs/issues with this module, perhaps
only this one. How about that general module project now Michael?   How
many more examples do I need to find before you make one?

[Michael Downey]

If we are going to have modules that are no longer actively maintained (like this and others), we need a way to mark modules as "unsupported" in the Module Repository until AMO or the equivalent is ready. After all, as Ben said himself in the disclaimer of the modrepo home page, "OpenMRS is providing links to these modules as a courtesy, and makes no representations regarding the modules or any information related there to. Any questions, complaints or claims regarding the modules must be directed to the appropriate module vendor." If we want to change that policy, that is something that can be debated, but it should be done publicly and consensus reached about a major change in approach.

A paradigm where add-on modules that are solely "community-supported" with no responsible named party or point of contact may have worked for a smaller project, but it neither feasible nor sustainable for a worldwide growing ecosystem.

What about adding '[Unsupported]' to orphaned modules or those that are no longer being actively maintained? When AMO (or similar) goes online we could mark them more clearly.

[Ben Wolfe]

Why must you dance around the issue? And why are we having this discussion
on this ticket?

The issue at hand: We need to put this ticket someplace. It does not belong
in TRUNK, it does not belong in its own project (yet). Where to put it?

[Michael Downey]

As I suggested above, this and all issues for modules belong in the possession of the maintainer of that module in whatever form (e.g., JIRA or other issue tracker, email, post-it note, text file, etc.) that person chooses for support of that module. For unsupported modules, the ticket should be cancelled/closed and marked as non-supported.

Put more succinctly: For this specific module, either (a) an individual can volunteer to become responsible for its care-taking, and subsequently consider working on the issue reported here, or (b) it should be retired and marked as such somehow, and this should ticket be cancelled as a result.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Mark Goodrich-2 Mark Goodrich-2
Reply | Threaded
Open this post in threaded view
|

Re: community-supported module resources

Personally, I think if there is a reasonable consensus amongst the core members of the community that a specific module should have its own jira project, it should get its own jira project… 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Tuesday, March 08, 2011 3:29 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] community-supported module resources

 

There's great strength in keeping modules (their documentation, code, and tickets) under the OpenMRS umbrella, because:

  • it allows devs to easily step in and contribute code to a module
  • it allows users to easily go to one place for support and bugs, even with different module "vendors"
  • it allows module ownership to transition between people over time

That last point is particularly important. The form2program module used to be owned by Brian. Now it's owned by "nobody" (but I'd rather phrase that, like Ben does, as "the general OpenMRS community"). Maybe in the future some individual will pick it up. Maybe an organization will build an OpenMRS distribution that bundles that module, and take some ownership. But there's no need to mark all its tickets as "denied" as long as they don't have an owner.

 

(+1000 for a "random modules" jira project)

 

-Darius

 

On Tue, Mar 8, 2011 at 2:41 PM, Jeremy Keiper <[hidden email]> wrote:

All -

 

We (Michael, Ben and Jeremy) have a brewing debate that we would like to open up to the community for resolution.  The concern is about providing project-specific ticketing mechanisms for unsupported (or sporadically community-maintained) modules.  It began when a contributor accidentally worked on a core patch for TRUNK-1815 when the patch was needed on the Form2Program Module.  Below is the current dialog.  Please contribute and help us resolve it before we all lose what hair we have left.  Thanks!

 

[Michael Downey]

 

The maintainer of the Form2Program module should be made aware of the issue and this issue either closed/cancelled or moved to a project if that person wants one in JIRA.

 

[Ben Wolfe]

 

The "maintainer" is the general community since the original author is

gone. I assume there will not be many bugs/issues with this module, perhaps

only this one. How about that general module project now Michael?   How

many more examples do I need to find before you make one?

 

[Michael Downey]

 

If we are going to have modules that are no longer actively maintained (like this and others), we need a way to mark modules as "unsupported" in the Module Repository until AMO or the equivalent is ready. After all, as Ben said himself in the disclaimer of the modrepo home page, "OpenMRS is providing links to these modules as a courtesy, and makes no representations regarding the modules or any information related there to. Any questions, complaints or claims regarding the modules must be directed to the appropriate module vendor." If we want to change that policy, that is something that can be debated, but it should be done publicly and consensus reached about a major change in approach.

 

A paradigm where add-on modules that are solely "community-supported" with no responsible named party or point of contact may have worked for a smaller project, but it neither feasible nor sustainable for a worldwide growing ecosystem.

 

What about adding '[Unsupported]' to orphaned modules or those that are no longer being actively maintained? When AMO (or similar) goes online we could mark them more clearly.

 

[Ben Wolfe]

 

Why must you dance around the issue? And why are we having this discussion

on this ticket?

 

The issue at hand: We need to put this ticket someplace. It does not belong

in TRUNK, it does not belong in its own project (yet). Where to put it?

 

[Michael Downey]

 

As I suggested above, this and all issues for modules belong in the possession of the maintainer of that module in whatever form (e.g., JIRA or other issue tracker, email, post-it note, text file, etc.) that person chooses for support of that module. For unsupported modules, the ticket should be cancelled/closed and marked as non-supported.

 

Put more succinctly: For this specific module, either (a) an individual can volunteer to become responsible for its care-taking, and subsequently consider working on the issue reported here, or (b) it should be retired and marked as such somehow, and this should ticket be cancelled as a result.


Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Michael Downey Michael Downey
Reply | Threaded
Open this post in threaded view
|

Re: community-supported module resources

The question of how to handle upstream (downstream) bug reports has been encountered in basically all large open source projects and I can't imagine the value in us reinventing the wheel. Generally, upstream bugs, when reported in the main project's issue tracker, are handled as follows:

1. Bug manager/triager verifies the problem really is upstream/downstream.
2. That person finds the support channel for that upstream/downstream product/add-on/module/library/etc.
3. Forward the issue to that support channel.
4. Notate the action and the final destination in the originally-reported issue and close the ticket (unless technology permits more sophisticated cross-system issue linking).

This standard process presupposes that our ecosystem of add-on software has clearly-defined owners, licenses, support mechanisms, compatibility, etc. -- which is often not the case today. 

Put bluntly, our "community library" of published modules is a mess. Lack of clarity about what's available may be keeping people from adopting OpenMRS.

I would love to see a review of all modules happen to ascertain if they are indeed still supported, and classify those that have been abandoned and belong to "nobody" (or, as Darius points out, the semantically-similar collective "community" -- if the license allows it). Again, if permitted by the original creator, another person could pick up maintenance of those modules if they so desire. Part of this identification process needs to be asking the module's maintainer how they wish to support their module. We should be flexible to their wishes and not "force" them to use our tools, although we should in most cases welcome them to do so if their software is of universal benefit to the larger OpenMRS community.

As mentioned in past developer meetings, we have begun evaluations on alternatives to our current module repository that will allow us to do this better. Meanwhile, I think there are likely some creative workarounds we could come up with to move toward these goals.

Thoughts?

Michael Downey
OpenMRS Community Infrastructure Team
[hidden email] - http://openmrs.org/

On Tuesday, March 8, 2011 at 3:45 PM, Mark Goodrich wrote:

Personally, I think if there is a reasonable consensus amongst the core members of the community that a specific module should have its own jira project, it should get its own jira project… 

 

From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri
Sent: Tuesday, March 08, 2011 3:29 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] community-supported module resources

 

There's great strength in keeping modules (their documentation, code, and tickets) under the OpenMRS umbrella, because:

  • it allows devs to easily step in and contribute code to a module
  • it allows users to easily go to one place for support and bugs, even with different module "vendors"
  • it allows module ownership to transition between people over time

That last point is particularly important. The form2program module used to be owned by Brian. Now it's owned by "nobody" (but I'd rather phrase that, like Ben does, as "the general OpenMRS community"). Maybe in the future some individual will pick it up. Maybe an organization will build an OpenMRS distribution that bundles that module, and take some ownership. But there's no need to mark all its tickets as "denied" as long as they don't have an owner.

 

(+1000 for a "random modules" jira project)

 

-Darius

 

On Tue, Mar 8, 2011 at 2:41 PM, Jeremy Keiper <[hidden email]> wrote:

All -

 

We (Michael, Ben and Jeremy) have a brewing debate that we would like to open up to the community for resolution.  The concern is about providing project-specific ticketing mechanisms for unsupported (or sporadically community-maintained) modules.  It began when a contributor accidentally worked on a core patch for TRUNK-1815 when the patch was needed on the Form2Program Module.  Below is the current dialog.  Please contribute and help us resolve it before we all lose what hair we have left.  Thanks!

 

[Michael Downey]

 

The maintainer of the Form2Program module should be made aware of the issue and this issue either closed/cancelled or moved to a project if that person wants one in JIRA.

 

[Ben Wolfe]

 

The "maintainer" is the general community since the original author is

gone. I assume there will not be many bugs/issues with this module, perhaps

only this one. How about that general module project now Michael?   How

many more examples do I need to find before you make one?

 

[Michael Downey]

 

If we are going to have modules that are no longer actively maintained (like this and others), we need a way to mark modules as "unsupported" in the Module Repository until AMO or the equivalent is ready. After all, as Ben said himself in the disclaimer of the modrepo home page, "OpenMRS is providing links to these modules as a courtesy, and makes no representations regarding the modules or any information related there to. Any questions, complaints or claims regarding the modules must be directed to the appropriate module vendor." If we want to change that policy, that is something that can be debated, but it should be done publicly and consensus reached about a major change in approach.

 

A paradigm where add-on modules that are solely "community-supported" with no responsible named party or point of contact may have worked for a smaller project, but it neither feasible nor sustainable for a worldwide growing ecosystem.

 

What about adding '[Unsupported]' to orphaned modules or those that are no longer being actively maintained? When AMO (or similar) goes online we could mark them more clearly.

 

[Ben Wolfe]

 

Why must you dance around the issue? And why are we having this discussion

on this ticket?

 

The issue at hand: We need to put this ticket someplace. It does not belong

in TRUNK, it does not belong in its own project (yet). Where to put it?

 

[Michael Downey]

 

As I suggested above, this and all issues for modules belong in the possession of the maintainer of that module in whatever form (e.g., JIRA or other issue tracker, email, post-it note, text file, etc.) that person chooses for support of that module. For unsupported modules, the ticket should be cancelled/closed and marked as non-supported.

 

Put more succinctly: For this specific module, either (a) an individual can volunteer to become responsible for its care-taking, and subsequently consider working on the issue reported here, or (b) it should be retired and marked as such somehow, and this should ticket be cancelled as a result.


Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: community-supported module resources

None of that answers the initial question. 

We have module tickets in the jira TRUNK project.  They don't have jira projects themselves yet.  Where to put them?

The answer is not "close them".  And the answer is not "require every module to have its own jira instance or even jira project.  Any module can have a project in our jira, thats not debated (or debatable) either.

These tickets should sit somewhere and allow volunteers to see/fix them easily.  Again, this is not in the TRUNK project.  If the volunteer wants to spend their time fixing that module, great!  If they want to take over "ownership" of that because the original dev cannot be reached, even better!  There may be 20 modules with 1 ticket each and those modules may have a max of 2 tickets over their lifespan.  Best to have a "Other Module" project in jira than 20 more projects cluttering up jira.

Getting a nice module/add-on/plugin repository is tangential...and not even debated.  It needs to happen.

Ben

On Tue, Mar 8, 2011 at 3:58 PM, Michael Downey <[hidden email]> wrote:
The question of how to handle upstream (downstream) bug reports has been encountered in basically all large open source projects and I can't imagine the value in us reinventing the wheel. Generally, upstream bugs, when reported in the main project's issue tracker, are handled as follows:

1. Bug manager/triager verifies the problem really is upstream/downstream.
2. That person finds the support channel for that upstream/downstream product/add-on/module/library/etc.
3. Forward the issue to that support channel.
4. Notate the action and the final destination in the originally-reported issue and close the ticket (unless technology permits more sophisticated cross-system issue linking).

This standard process presupposes that our ecosystem of add-on software has clearly-defined owners, licenses, support mechanisms, compatibility, etc. -- which is often not the case today. 

Put bluntly, our "community library" of published modules is a mess. Lack of clarity about what's available may be keeping people from adopting OpenMRS.

I would love to see a review of all modules happen to ascertain if they are indeed still supported, and classify those that have been abandoned and belong to "nobody" (or, as Darius points out, the semantically-similar collective "community" -- if the license allows it). Again, if permitted by the original creator, another person could pick up maintenance of those modules if they so desire. Part of this identification process needs to be asking the module's maintainer how they wish to support their module. We should be flexible to their wishes and not "force" them to use our tools, although we should in most cases welcome them to do so if their software is of universal benefit to the larger OpenMRS community.

As mentioned in past developer meetings, we have begun evaluations on alternatives to our current module repository that will allow us to do this better. Meanwhile, I think there are likely some creative workarounds we could come up with to move toward these goals.

Thoughts?

Michael Downey
OpenMRS Community Infrastructure Team

On Tuesday, March 8, 2011 at 3:45 PM, Mark Goodrich wrote:

Personally, I think if there is a reasonable consensus amongst the core members of the community that a specific module should have its own jira project, it should get its own jira project… 

 

From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri
Sent: Tuesday, March 08, 2011 3:29 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] community-supported module resources

 

There's great strength in keeping modules (their documentation, code, and tickets) under the OpenMRS umbrella, because:

  • it allows devs to easily step in and contribute code to a module
  • it allows users to easily go to one place for support and bugs, even with different module "vendors"
  • it allows module ownership to transition between people over time

That last point is particularly important. The form2program module used to be owned by Brian. Now it's owned by "nobody" (but I'd rather phrase that, like Ben does, as "the general OpenMRS community"). Maybe in the future some individual will pick it up. Maybe an organization will build an OpenMRS distribution that bundles that module, and take some ownership. But there's no need to mark all its tickets as "denied" as long as they don't have an owner.

 

(+1000 for a "random modules" jira project)

 

-Darius

 

On Tue, Mar 8, 2011 at 2:41 PM, Jeremy Keiper <[hidden email]> wrote:

All -

 

We (Michael, Ben and Jeremy) have a brewing debate that we would like to open up to the community for resolution.  The concern is about providing project-specific ticketing mechanisms for unsupported (or sporadically community-maintained) modules.  It began when a contributor accidentally worked on a core patch for TRUNK-1815 when the patch was needed on the Form2Program Module.  Below is the current dialog.  Please contribute and help us resolve it before we all lose what hair we have left.  Thanks!

 

[Michael Downey]

 

The maintainer of the Form2Program module should be made aware of the issue and this issue either closed/cancelled or moved to a project if that person wants one in JIRA.

 

[Ben Wolfe]

 

The "maintainer" is the general community since the original author is

gone. I assume there will not be many bugs/issues with this module, perhaps

only this one. How about that general module project now Michael?   How

many more examples do I need to find before you make one?

 

[Michael Downey]

 

If we are going to have modules that are no longer actively maintained (like this and others), we need a way to mark modules as "unsupported" in the Module Repository until AMO or the equivalent is ready. After all, as Ben said himself in the disclaimer of the modrepo home page, "OpenMRS is providing links to these modules as a courtesy, and makes no representations regarding the modules or any information related there to. Any questions, complaints or claims regarding the modules must be directed to the appropriate module vendor." If we want to change that policy, that is something that can be debated, but it should be done publicly and consensus reached about a major change in approach.

 

A paradigm where add-on modules that are solely "community-supported" with no responsible named party or point of contact may have worked for a smaller project, but it neither feasible nor sustainable for a worldwide growing ecosystem.

 

What about adding '[Unsupported]' to orphaned modules or those that are no longer being actively maintained? When AMO (or similar) goes online we could mark them more clearly.

 

[Ben Wolfe]

 

Why must you dance around the issue? And why are we having this discussion

on this ticket?

 

The issue at hand: We need to put this ticket someplace. It does not belong

in TRUNK, it does not belong in its own project (yet). Where to put it?

 

[Michael Downey]

 

As I suggested above, this and all issues for modules belong in the possession of the maintainer of that module in whatever form (e.g., JIRA or other issue tracker, email, post-it note, text file, etc.) that person chooses for support of that module. For unsupported modules, the ticket should be cancelled/closed and marked as non-supported.

 

Put more succinctly: For this specific module, either (a) an individual can volunteer to become responsible for its care-taking, and subsequently consider working on the issue reported here, or (b) it should be retired and marked as such somehow, and this should ticket be cancelled as a result.


Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: community-supported module resources

To echo: there are two viable solutions to someone creating a form2program ticket in TRUNK:

1. Move it to the "other modules" project. (This is also my preferred solution. I agree with Ben.)
2. Create a "form2program module" project and move it there.

There are no other acceptable solutions today.

It is fair to have a big-picture discussion about whether or not OpenMRS should provide infrastructure support for modules. But as of today we provide svn, tickets, and omod hosting for any module that wants it.

-Darius

On Tue, Mar 8, 2011 at 4:26 PM, Ben Wolfe <[hidden email]> wrote:
None of that answers the initial question. 

We have module tickets in the jira TRUNK project.  They don't have jira projects themselves yet.  Where to put them?

The answer is not "close them".  And the answer is not "require every module to have its own jira instance or even jira project.  Any module can have a project in our jira, thats not debated (or debatable) either.

These tickets should sit somewhere and allow volunteers to see/fix them easily.  Again, this is not in the TRUNK project.  If the volunteer wants to spend their time fixing that module, great!  If they want to take over "ownership" of that because the original dev cannot be reached, even better!  There may be 20 modules with 1 ticket each and those modules may have a max of 2 tickets over their lifespan.  Best to have a "Other Module" project in jira than 20 more projects cluttering up jira.

Getting a nice module/add-on/plugin repository is tangential...and not even debated.  It needs to happen.

Ben


On Tue, Mar 8, 2011 at 3:58 PM, Michael Downey <[hidden email]> wrote:
The question of how to handle upstream (downstream) bug reports has been encountered in basically all large open source projects and I can't imagine the value in us reinventing the wheel. Generally, upstream bugs, when reported in the main project's issue tracker, are handled as follows:

1. Bug manager/triager verifies the problem really is upstream/downstream.
2. That person finds the support channel for that upstream/downstream product/add-on/module/library/etc.
3. Forward the issue to that support channel.
4. Notate the action and the final destination in the originally-reported issue and close the ticket (unless technology permits more sophisticated cross-system issue linking).

This standard process presupposes that our ecosystem of add-on software has clearly-defined owners, licenses, support mechanisms, compatibility, etc. -- which is often not the case today. 

Put bluntly, our "community library" of published modules is a mess. Lack of clarity about what's available may be keeping people from adopting OpenMRS.

I would love to see a review of all modules happen to ascertain if they are indeed still supported, and classify those that have been abandoned and belong to "nobody" (or, as Darius points out, the semantically-similar collective "community" -- if the license allows it). Again, if permitted by the original creator, another person could pick up maintenance of those modules if they so desire. Part of this identification process needs to be asking the module's maintainer how they wish to support their module. We should be flexible to their wishes and not "force" them to use our tools, although we should in most cases welcome them to do so if their software is of universal benefit to the larger OpenMRS community.

As mentioned in past developer meetings, we have begun evaluations on alternatives to our current module repository that will allow us to do this better. Meanwhile, I think there are likely some creative workarounds we could come up with to move toward these goals.

Thoughts?

Michael Downey
OpenMRS Community Infrastructure Team

On Tuesday, March 8, 2011 at 3:45 PM, Mark Goodrich wrote:

Personally, I think if there is a reasonable consensus amongst the core members of the community that a specific module should have its own jira project, it should get its own jira project… 

 

From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri
Sent: Tuesday, March 08, 2011 3:29 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] community-supported module resources

 

There's great strength in keeping modules (their documentation, code, and tickets) under the OpenMRS umbrella, because:

  • it allows devs to easily step in and contribute code to a module
  • it allows users to easily go to one place for support and bugs, even with different module "vendors"
  • it allows module ownership to transition between people over time

That last point is particularly important. The form2program module used to be owned by Brian. Now it's owned by "nobody" (but I'd rather phrase that, like Ben does, as "the general OpenMRS community"). Maybe in the future some individual will pick it up. Maybe an organization will build an OpenMRS distribution that bundles that module, and take some ownership. But there's no need to mark all its tickets as "denied" as long as they don't have an owner.

 

(+1000 for a "random modules" jira project)

 

-Darius

 

On Tue, Mar 8, 2011 at 2:41 PM, Jeremy Keiper <[hidden email]> wrote:

All -

 

We (Michael, Ben and Jeremy) have a brewing debate that we would like to open up to the community for resolution.  The concern is about providing project-specific ticketing mechanisms for unsupported (or sporadically community-maintained) modules.  It began when a contributor accidentally worked on a core patch for TRUNK-1815 when the patch was needed on the Form2Program Module.  Below is the current dialog.  Please contribute and help us resolve it before we all lose what hair we have left.  Thanks!

 

[Michael Downey]

 

The maintainer of the Form2Program module should be made aware of the issue and this issue either closed/cancelled or moved to a project if that person wants one in JIRA.

 

[Ben Wolfe]

 

The "maintainer" is the general community since the original author is

gone. I assume there will not be many bugs/issues with this module, perhaps

only this one. How about that general module project now Michael?   How

many more examples do I need to find before you make one?

 

[Michael Downey]

 

If we are going to have modules that are no longer actively maintained (like this and others), we need a way to mark modules as "unsupported" in the Module Repository until AMO or the equivalent is ready. After all, as Ben said himself in the disclaimer of the modrepo home page, "OpenMRS is providing links to these modules as a courtesy, and makes no representations regarding the modules or any information related there to. Any questions, complaints or claims regarding the modules must be directed to the appropriate module vendor." If we want to change that policy, that is something that can be debated, but it should be done publicly and consensus reached about a major change in approach.

 

A paradigm where add-on modules that are solely "community-supported" with no responsible named party or point of contact may have worked for a smaller project, but it neither feasible nor sustainable for a worldwide growing ecosystem.

 

What about adding '[Unsupported]' to orphaned modules or those that are no longer being actively maintained? When AMO (or similar) goes online we could mark them more clearly.

 

[Ben Wolfe]

 

Why must you dance around the issue? And why are we having this discussion

on this ticket?

 

The issue at hand: We need to put this ticket someplace. It does not belong

in TRUNK, it does not belong in its own project (yet). Where to put it?

 

[Michael Downey]

 

As I suggested above, this and all issues for modules belong in the possession of the maintainer of that module in whatever form (e.g., JIRA or other issue tracker, email, post-it note, text file, etc.) that person chooses for support of that module. For unsupported modules, the ticket should be cancelled/closed and marked as non-supported.

 

Put more succinctly: For this specific module, either (a) an individual can volunteer to become responsible for its care-taking, and subsequently consider working on the issue reported here, or (b) it should be retired and marked as such somehow, and this should ticket be cancelled as a result.


Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Michael Downey Michael Downey
Reply | Threaded
Open this post in threaded view
|

Re: community-supported module resources

In reply to this post by Ben Wolfe (openmrs)
Hey, Ben ... I'm not sure how to be any more succinct:

"The reports should be transferred to whatever that module's support channel (issue tracker, email, etc.) has elected to use."

Step 3 in the list below, "forward the issue to that support channel", is the most critical step. We owe it to our community to make sure the developers of modules published in our repository have thought about how to handle support, and we should respect that developer's decision by using that channel to forward issues. 

Two problems:

1. Not all modules have clearly-established maintainers.
2. For those that do, a support channel may not yet have been decided.

For those modules that have someone maintaining them, if that person hasn't thought about support yet, we should have them decide what they want to do for support and publish that information for our users in the module repository.

And so, if modules exist in our repository that have no one taking care of them, we owe it to our community to either (a) be honest & clear that the module is NOT currently being supported by anyone, or (b) find someone to take responsibility for supporting it. 

Form2program hasn't been touched in 3 years, when OpenMRS 1.2 was the latest and greatest. Does anyone want to volunteer to take ownership of it?

If we can undertake this "audit" of modules and require a support mechanism to be defined for each one (e-mail, OpenMRS JIRA, Sourceforge Trac, or *whatever they want*) ... then the question of what to do with tickets in our tracker becomes moot. I strongly believe it's not only worth the effort, but critical to do so. In fact, even though I may not be the best person for the job, I will do it myself in my spare time if no one else is willing or interested in helping.

I also strongly disagree with the idea that "any" module per se can have a project in the main JIRA instance. I think (and as Darius said, we should discuss the idea) that we should limit those projects to non-commercial, open source modules that are of benefit to a larger audience than only the developer themselves. I also strongly disagree with your claim that having many projects "clutters" JIRA. The UI has greatly improved to categorize and limit views to the project at hand. We should warmly welcome community developers who want to host their issue tracking with us.

-Michael


On Tuesday, March 8, 2011 at 4:26 PM, Ben Wolfe wrote:
None of that answers the initial question. 

We have module tickets in the jira TRUNK project.  They don't have jira projects themselves yet.  Where to put them?

The answer is not "close them".  And the answer is not "require every module to have its own jira instance or even jira project.  Any module can have a project in our jira, thats not debated (or debatable) either.

These tickets should sit somewhere and allow volunteers to see/fix them easily.  Again, this is not in the TRUNK project.  If the volunteer wants to spend their time fixing that module, great!  If they want to take over "ownership" of that because the original dev cannot be reached, even better!  There may be 20 modules with 1 ticket each and those modules may have a max of 2 tickets over their lifespan.  Best to have a "Other Module" project in jira than 20 more projects cluttering up jira.

Getting a nice module/add-on/plugin repository is tangential...and not even debated.  It needs to happen.

Ben

On Tue, Mar 8, 2011 at 3:58 PM, Michael Downey <[hidden email]> wrote:
The question of how to handle upstream (downstream) bug reports has been encountered in basically all large open source projects and I can't imagine the value in us reinventing the wheel. Generally, upstream bugs, when reported in the main project's issue tracker, are handled as follows:

1. Bug manager/triager verifies the problem really is upstream/downstream.
2. That person finds the support channel for that upstream/downstream product/add-on/module/library/etc.
3. Forward the issue to that support channel.
4. Notate the action and the final destination in the originally-reported issue and close the ticket (unless technology permits more sophisticated cross-system issue linking).

This standard process presupposes that our ecosystem of add-on software has clearly-defined owners, licenses, support mechanisms, compatibility, etc. -- which is often not the case today. 

Put bluntly, our "community library" of published modules is a mess. Lack of clarity about what's available may be keeping people from adopting OpenMRS.

I would love to see a review of all modules happen to ascertain if they are indeed still supported, and classify those that have been abandoned and belong to "nobody" (or, as Darius points out, the semantically-similar collective "community" -- if the license allows it). Again, if permitted by the original creator, another person could pick up maintenance of those modules if they so desire. Part of this identification process needs to be asking the module's maintainer how they wish to support their module. We should be flexible to their wishes and not "force" them to use our tools, although we should in most cases welcome them to do so if their software is of universal benefit to the larger OpenMRS community.

As mentioned in past developer meetings, we have begun evaluations on alternatives to our current module repository that will allow us to do this better. Meanwhile, I think there are likely some creative workarounds we could come up with to move toward these goals.

Thoughts?

Michael Downey
OpenMRS Community Infrastructure Team

On Tuesday, March 8, 2011 at 3:45 PM, Mark Goodrich wrote:

Personally, I think if there is a reasonable consensus amongst the core members of the community that a specific module should have its own jira project, it should get its own jira project… 

 

From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri
Sent: Tuesday, March 08, 2011 3:29 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] community-supported module resources

 

There's great strength in keeping modules (their documentation, code, and tickets) under the OpenMRS umbrella, because:

  • it allows devs to easily step in and contribute code to a module
  • it allows users to easily go to one place for support and bugs, even with different module "vendors"
  • it allows module ownership to transition between people over time

That last point is particularly important. The form2program module used to be owned by Brian. Now it's owned by "nobody" (but I'd rather phrase that, like Ben does, as "the general OpenMRS community"). Maybe in the future some individual will pick it up. Maybe an organization will build an OpenMRS distribution that bundles that module, and take some ownership. But there's no need to mark all its tickets as "denied" as long as they don't have an owner.

 

(+1000 for a "random modules" jira project)

 

-Darius

 

On Tue, Mar 8, 2011 at 2:41 PM, Jeremy Keiper <[hidden email]> wrote:

All -

 

We (Michael, Ben and Jeremy) have a brewing debate that we would like to open up to the community for resolution.  The concern is about providing project-specific ticketing mechanisms for unsupported (or sporadically community-maintained) modules.  It began when a contributor accidentally worked on a core patch for TRUNK-1815 when the patch was needed on the Form2Program Module.  Below is the current dialog.  Please contribute and help us resolve it before we all lose what hair we have left.  Thanks!

 

[Michael Downey]

 

The maintainer of the Form2Program module should be made aware of the issue and this issue either closed/cancelled or moved to a project if that person wants one in JIRA.

 

[Ben Wolfe]

 

The "maintainer" is the general community since the original author is

gone. I assume there will not be many bugs/issues with this module, perhaps

only this one. How about that general module project now Michael?   How

many more examples do I need to find before you make one?

 

[Michael Downey]

 

If we are going to have modules that are no longer actively maintained (like this and others), we need a way to mark modules as "unsupported" in the Module Repository until AMO or the equivalent is ready. After all, as Ben said himself in the disclaimer of the modrepo home page, "OpenMRS is providing links to these modules as a courtesy, and makes no representations regarding the modules or any information related there to. Any questions, complaints or claims regarding the modules must be directed to the appropriate module vendor." If we want to change that policy, that is something that can be debated, but it should be done publicly and consensus reached about a major change in approach.

 

A paradigm where add-on modules that are solely "community-supported" with no responsible named party or point of contact may have worked for a smaller project, but it neither feasible nor sustainable for a worldwide growing ecosystem.

 

What about adding '[Unsupported]' to orphaned modules or those that are no longer being actively maintained? When AMO (or similar) goes online we could mark them more clearly.

 

[Ben Wolfe]

 

Why must you dance around the issue? And why are we having this discussion

on this ticket?

 

The issue at hand: We need to put this ticket someplace. It does not belong

in TRUNK, it does not belong in its own project (yet). Where to put it?

 

[Michael Downey]

 

As I suggested above, this and all issues for modules belong in the possession of the maintainer of that module in whatever form (e.g., JIRA or other issue tracker, email, post-it note, text file, etc.) that person chooses for support of that module. For unsupported modules, the ticket should be cancelled/closed and marked as non-supported.

 

Put more succinctly: For this specific module, either (a) an individual can volunteer to become responsible for its care-taking, and subsequently consider working on the issue reported here, or (b) it should be retired and marked as such somehow, and this should ticket be cancelled as a result.


Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: community-supported module resources

I've added this to the agenda for this Thursday's dev call.

-Burke

On Tue, Mar 8, 2011 at 5:02 PM, Michael Downey <[hidden email]> wrote:
Hey, Ben ... I'm not sure how to be any more succinct:

"The reports should be transferred to whatever that module's support channel (issue tracker, email, etc.) has elected to use."

Step 3 in the list below, "forward the issue to that support channel", is the most critical step. We owe it to our community to make sure the developers of modules published in our repository have thought about how to handle support, and we should respect that developer's decision by using that channel to forward issues. 

Two problems:

1. Not all modules have clearly-established maintainers.
2. For those that do, a support channel may not yet have been decided.

For those modules that have someone maintaining them, if that person hasn't thought about support yet, we should have them decide what they want to do for support and publish that information for our users in the module repository.

And so, if modules exist in our repository that have no one taking care of them, we owe it to our community to either (a) be honest & clear that the module is NOT currently being supported by anyone, or (b) find someone to take responsibility for supporting it. 

Form2program hasn't been touched in 3 years, when OpenMRS 1.2 was the latest and greatest. Does anyone want to volunteer to take ownership of it?

If we can undertake this "audit" of modules and require a support mechanism to be defined for each one (e-mail, OpenMRS JIRA, Sourceforge Trac, or *whatever they want*) ... then the question of what to do with tickets in our tracker becomes moot. I strongly believe it's not only worth the effort, but critical to do so. In fact, even though I may not be the best person for the job, I will do it myself in my spare time if no one else is willing or interested in helping.

I also strongly disagree with the idea that "any" module per se can have a project in the main JIRA instance. I think (and as Darius said, we should discuss the idea) that we should limit those projects to non-commercial, open source modules that are of benefit to a larger audience than only the developer themselves. I also strongly disagree with your claim that having many projects "clutters" JIRA. The UI has greatly improved to categorize and limit views to the project at hand. We should warmly welcome community developers who want to host their issue tracking with us.

-Michael


On Tuesday, March 8, 2011 at 4:26 PM, Ben Wolfe wrote:
None of that answers the initial question. 

We have module tickets in the jira TRUNK project.  They don't have jira projects themselves yet.  Where to put them?

The answer is not "close them".  And the answer is not "require every module to have its own jira instance or even jira project.  Any module can have a project in our jira, thats not debated (or debatable) either.

These tickets should sit somewhere and allow volunteers to see/fix them easily.  Again, this is not in the TRUNK project.  If the volunteer wants to spend their time fixing that module, great!  If they want to take over "ownership" of that because the original dev cannot be reached, even better!  There may be 20 modules with 1 ticket each and those modules may have a max of 2 tickets over their lifespan.  Best to have a "Other Module" project in jira than 20 more projects cluttering up jira.

Getting a nice module/add-on/plugin repository is tangential...and not even debated.  It needs to happen.

Ben

On Tue, Mar 8, 2011 at 3:58 PM, Michael Downey <[hidden email]> wrote:
The question of how to handle upstream (downstream) bug reports has been encountered in basically all large open source projects and I can't imagine the value in us reinventing the wheel. Generally, upstream bugs, when reported in the main project's issue tracker, are handled as follows:

1. Bug manager/triager verifies the problem really is upstream/downstream.
2. That person finds the support channel for that upstream/downstream product/add-on/module/library/etc.
3. Forward the issue to that support channel.
4. Notate the action and the final destination in the originally-reported issue and close the ticket (unless technology permits more sophisticated cross-system issue linking).

This standard process presupposes that our ecosystem of add-on software has clearly-defined owners, licenses, support mechanisms, compatibility, etc. -- which is often not the case today. 

Put bluntly, our "community library" of published modules is a mess. Lack of clarity about what's available may be keeping people from adopting OpenMRS.

I would love to see a review of all modules happen to ascertain if they are indeed still supported, and classify those that have been abandoned and belong to "nobody" (or, as Darius points out, the semantically-similar collective "community" -- if the license allows it). Again, if permitted by the original creator, another person could pick up maintenance of those modules if they so desire. Part of this identification process needs to be asking the module's maintainer how they wish to support their module. We should be flexible to their wishes and not "force" them to use our tools, although we should in most cases welcome them to do so if their software is of universal benefit to the larger OpenMRS community.

As mentioned in past developer meetings, we have begun evaluations on alternatives to our current module repository that will allow us to do this better. Meanwhile, I think there are likely some creative workarounds we could come up with to move toward these goals.

Thoughts?

Michael Downey
OpenMRS Community Infrastructure Team

On Tuesday, March 8, 2011 at 3:45 PM, Mark Goodrich wrote:

Personally, I think if there is a reasonable consensus amongst the core members of the community that a specific module should have its own jira project, it should get its own jira project… 

 

From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri
Sent: Tuesday, March 08, 2011 3:29 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] community-supported module resources

 

There's great strength in keeping modules (their documentation, code, and tickets) under the OpenMRS umbrella, because:

  • it allows devs to easily step in and contribute code to a module
  • it allows users to easily go to one place for support and bugs, even with different module "vendors"
  • it allows module ownership to transition between people over time

That last point is particularly important. The form2program module used to be owned by Brian. Now it's owned by "nobody" (but I'd rather phrase that, like Ben does, as "the general OpenMRS community"). Maybe in the future some individual will pick it up. Maybe an organization will build an OpenMRS distribution that bundles that module, and take some ownership. But there's no need to mark all its tickets as "denied" as long as they don't have an owner.

 

(+1000 for a "random modules" jira project)

 

-Darius

 

On Tue, Mar 8, 2011 at 2:41 PM, Jeremy Keiper <[hidden email]> wrote:

All -

 

We (Michael, Ben and Jeremy) have a brewing debate that we would like to open up to the community for resolution.  The concern is about providing project-specific ticketing mechanisms for unsupported (or sporadically community-maintained) modules.  It began when a contributor accidentally worked on a core patch for TRUNK-1815 when the patch was needed on the Form2Program Module.  Below is the current dialog.  Please contribute and help us resolve it before we all lose what hair we have left.  Thanks!

 

[Michael Downey]

 

The maintainer of the Form2Program module should be made aware of the issue and this issue either closed/cancelled or moved to a project if that person wants one in JIRA.

 

[Ben Wolfe]

 

The "maintainer" is the general community since the original author is

gone. I assume there will not be many bugs/issues with this module, perhaps

only this one. How about that general module project now Michael?   How

many more examples do I need to find before you make one?

 

[Michael Downey]

 

If we are going to have modules that are no longer actively maintained (like this and others), we need a way to mark modules as "unsupported" in the Module Repository until AMO or the equivalent is ready. After all, as Ben said himself in the disclaimer of the modrepo home page, "OpenMRS is providing links to these modules as a courtesy, and makes no representations regarding the modules or any information related there to. Any questions, complaints or claims regarding the modules must be directed to the appropriate module vendor." If we want to change that policy, that is something that can be debated, but it should be done publicly and consensus reached about a major change in approach.

 

A paradigm where add-on modules that are solely "community-supported" with no responsible named party or point of contact may have worked for a smaller project, but it neither feasible nor sustainable for a worldwide growing ecosystem.

 

What about adding '[Unsupported]' to orphaned modules or those that are no longer being actively maintained? When AMO (or similar) goes online we could mark them more clearly.

 

[Ben Wolfe]

 

Why must you dance around the issue? And why are we having this discussion

on this ticket?

 

The issue at hand: We need to put this ticket someplace. It does not belong

in TRUNK, it does not belong in its own project (yet). Where to put it?

 

[Michael Downey]

 

As I suggested above, this and all issues for modules belong in the possession of the maintainer of that module in whatever form (e.g., JIRA or other issue tracker, email, post-it note, text file, etc.) that person chooses for support of that module. For unsupported modules, the ticket should be cancelled/closed and marked as non-supported.

 

Put more succinctly: For this specific module, either (a) an individual can volunteer to become responsible for its care-taking, and subsequently consider working on the issue reported here, or (b) it should be retired and marked as such somehow, and this should ticket be cancelled as a result.


Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Dave Thomas Dave Thomas
Reply | Threaded
Open this post in threaded view
|

Re: community-supported module resources

In reply to this post by Ben Wolfe (openmrs)
Hi.  I just want to chime in to say that it is extremely useful (thank you, thank you) to be able to use OpenMRS project hosting for some of the Rwanda stuff, because of the transparency it provides, even though there's a lot of implementation-specific code in our modules (like the rwandaprimarycare module).  We've worked extremely hard this year to synchronize our efforts with the MoH, and public access to basically everything that we do has greatly diminished suspicions around 'PIH is working at cross-purposes' (which we're not).  It will be basically good for OpenMRS if we're successful this year in scaling up to country-wide health center implementations.  Its sounds like as long as projects have good support channels, that they qualify for using OpenMRS project resources, so it sounds like we're OK. 

I just think the political benefits for implementers (and OpenMRS by extension) of complete transparency is something to consider if the repository and JIRA rules are going to be formalized.

thanks,
d

On 3/8/2011 11:26 PM, Ben Wolfe wrote:
None of that answers the initial question. 

We have module tickets in the jira TRUNK project.  They don't have jira projects themselves yet.  Where to put them?

The answer is not "close them".  And the answer is not "require every module to have its own jira instance or even jira project.  Any module can have a project in our jira, thats not debated (or debatable) either.

These tickets should sit somewhere and allow volunteers to see/fix them easily.  Again, this is not in the TRUNK project.  If the volunteer wants to spend their time fixing that module, great!  If they want to take over "ownership" of that because the original dev cannot be reached, even better!  There may be 20 modules with 1 ticket each and those modules may have a max of 2 tickets over their lifespan.  Best to have a "Other Module" project in jira than 20 more projects cluttering up jira.

Getting a nice module/add-on/plugin repository is tangential...and not even debated.  It needs to happen.

Ben

On Tue, Mar 8, 2011 at 3:58 PM, Michael Downey <[hidden email]> wrote:
The question of how to handle upstream (downstream) bug reports has been encountered in basically all large open source projects and I can't imagine the value in us reinventing the wheel. Generally, upstream bugs, when reported in the main project's issue tracker, are handled as follows:

1. Bug manager/triager verifies the problem really is upstream/downstream.
2. That person finds the support channel for that upstream/downstream product/add-on/module/library/etc.
3. Forward the issue to that support channel.
4. Notate the action and the final destination in the originally-reported issue and close the ticket (unless technology permits more sophisticated cross-system issue linking).

This standard process presupposes that our ecosystem of add-on software has clearly-defined owners, licenses, support mechanisms, compatibility, etc. -- which is often not the case today. 

Put bluntly, our "community library" of published modules is a mess. Lack of clarity about what's available may be keeping people from adopting OpenMRS.

I would love to see a review of all modules happen to ascertain if they are indeed still supported, and classify those that have been abandoned and belong to "nobody" (or, as Darius points out, the semantically-similar collective "community" -- if the license allows it). Again, if permitted by the original creator, another person could pick up maintenance of those modules if they so desire. Part of this identification process needs to be asking the module's maintainer how they wish to support their module. We should be flexible to their wishes and not "force" them to use our tools, although we should in most cases welcome them to do so if their software is of universal benefit to the larger OpenMRS community.

As mentioned in past developer meetings, we have begun evaluations on alternatives to our current module repository that will allow us to do this better. Meanwhile, I think there are likely some creative workarounds we could come up with to move toward these goals.

Thoughts?

Michael Downey
OpenMRS Community Infrastructure Team

On Tuesday, March 8, 2011 at 3:45 PM, Mark Goodrich wrote:

Personally, I think if there is a reasonable consensus amongst the core members of the community that a specific module should have its own jira project, it should get its own jira project… 

 

From: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri
Sent: Tuesday, March 08, 2011 3:29 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] community-supported module resources

 

There's great strength in keeping modules (their documentation, code, and tickets) under the OpenMRS umbrella, because:

  • it allows devs to easily step in and contribute code to a module
  • it allows users to easily go to one place for support and bugs, even with different module "vendors"
  • it allows module ownership to transition between people over time

That last point is particularly important. The form2program module used to be owned by Brian. Now it's owned by "nobody" (but I'd rather phrase that, like Ben does, as "the general OpenMRS community"). Maybe in the future some individual will pick it up. Maybe an organization will build an OpenMRS distribution that bundles that module, and take some ownership. But there's no need to mark all its tickets as "denied" as long as they don't have an owner.

 

(+1000 for a "random modules" jira project)

 

-Darius

 

On Tue, Mar 8, 2011 at 2:41 PM, Jeremy Keiper <[hidden email]> wrote:

All -

 

We (Michael, Ben and Jeremy) have a brewing debate that we would like to open up to the community for resolution.  The concern is about providing project-specific ticketing mechanisms for unsupported (or sporadically community-maintained) modules.  It began when a contributor accidentally worked on a core patch for TRUNK-1815 when the patch was needed on the Form2Program Module.  Below is the current dialog.  Please contribute and help us resolve it before we all lose what hair we have left.  Thanks!

 

[Michael Downey]

 

The maintainer of the Form2Program module should be made aware of the issue and this issue either closed/cancelled or moved to a project if that person wants one in JIRA.

 

[Ben Wolfe]

 

The "maintainer" is the general community since the original author is

gone. I assume there will not be many bugs/issues with this module, perhaps

only this one. How about that general module project now Michael?   How

many more examples do I need to find before you make one?

 

[Michael Downey]

 

If we are going to have modules that are no longer actively maintained (like this and others), we need a way to mark modules as "unsupported" in the Module Repository until AMO or the equivalent is ready. After all, as Ben said himself in the disclaimer of the modrepo home page, "OpenMRS is providing links to these modules as a courtesy, and makes no representations regarding the modules or any information related there to. Any questions, complaints or claims regarding the modules must be directed to the appropriate module vendor." If we want to change that policy, that is something that can be debated, but it should be done publicly and consensus reached about a major change in approach.

 

A paradigm where add-on modules that are solely "community-supported" with no responsible named party or point of contact may have worked for a smaller project, but it neither feasible nor sustainable for a worldwide growing ecosystem.

 

What about adding '[Unsupported]' to orphaned modules or those that are no longer being actively maintained? When AMO (or similar) goes online we could mark them more clearly.

 

[Ben Wolfe]

 

Why must you dance around the issue? And why are we having this discussion

on this ticket?

 

The issue at hand: We need to put this ticket someplace. It does not belong

in TRUNK, it does not belong in its own project (yet). Where to put it?

 

[Michael Downey]

 

As I suggested above, this and all issues for modules belong in the possession of the maintainer of that module in whatever form (e.g., JIRA or other issue tracker, email, post-it note, text file, etc.) that person chooses for support of that module. For unsupported modules, the ticket should be cancelled/closed and marked as non-supported.

 

Put more succinctly: For this specific module, either (a) an individual can volunteer to become responsible for its care-taking, and subsequently consider working on the issue reported here, or (b) it should be retired and marked as such somehow, and this should ticket be cancelled as a result.


Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list