Re: New Repo Proposal - Vertical Health

by

Dave Lasley

- 06/12/2016 03:54:05

Vertical-Medical is realistically the closest repo match for it, but we’re at over 50 modules in my incubator with more planned. The scope of “Medical" repo is already quite large, so I propose defining a new scope of “Health” to compensate.

The line between Medical and Health is somewhat blurry, but I believe we could define as follows:

Health - Modules related to Patient statistics for non-laboratory type procedures. It would include things like diets, exercise schedules/stats, and other personal-type goals/statistics.

This data will likely be used by personal trainers, gyms, health food stores, etc.

For the most part, no companies using only these modules require licenses or specialty education to perform business.

This data is not considered protected under Healthcare specific legislation, such as HIPAA

From this thread, I think the issue sounds like we are just having growing pains as more and more modules come under the OCA umbrella. I will start a separate thread in the next few days on this & we can keep this one scoped at where the nutritional modules should go.

I am firmly against including these modules in Vertical Medical for the reasons outlined previously regarding the current depth of the repo in the incubators.

It sounds like we have two options here:

1. We expand the definition of scope of partner-contact to include a more broad definition of attributes that can be added to partners.

Repository organization should be guided by application area.The most important thing about this grouping is to ensure focus from the maintainer team.

Nutrition-related modules form a group that should be kept together in the same repository.They were being hosted at Partner-contact, but I don't thing they fit the purpose of that repo.vertical-medical is the next best candidate, but medical features are a separate thing from nutrition.

Keeping the principle that we should keep repos as much focused as possible, I think it would be best to have a separate repo for these features.

The whole vertical organisation is more contraproductive than it really helps. Some modules i.e. need to be used in several verticals. On the otherhand you can't really find modules you need because they have no own repository.

With gitup -c you could easily monitor which module really got updated and which is already compatible with v10. Instead you need now multiple manual steps because of verticals which are a repository with tons of submodules.

Each module in an own repository and those linked in vertical group lists would make things more transparent.

Those linked repo lists could also be easier to be adjust to current versions. It really does make much sense that all oca repos look like they are version 10 and when you look inside some modules are not even working in 9. It is a great illusion causing frustration also with customers who check those and think they all have already been ported.

Much better would be to have those linked list to each single module repo!

Additionally, I have expanded Vertical Medical to more than 50 modules in my incubator. I’m having a serious organization problem right now as it is to be honest, and am trying to offload as much logic as possible.

I am not against more repositories, but even in the last months it has been better for me have less modules than more modules, the same for repositories (even if it is technically feasible administer a lot of repositories) in terms of design it is too difficult to respect in the meanwhile the separated design and we are being frequently lost in what already exists or not exist.