Update quidel covidtest docstrings to pass pydocstyle

[chinandrew]

Summary of changes:

• Update docstrings so they pass the pydocstyle linter, which checks against most of PEP257
• geomapping and data tools (smoothing) functions are excluded until refactors go through

[jingjtang]

@chinandrew quidel_covidtest is branch that is more up-to-date and is also the branch that is used for automation, can you merge this to that branch instead of main ?

[chinandrew]

@chinandrew quidel_covidtest is branch that is more up-to-date and is also the branch that is used for automation, can you merge this to that branch instead of main ?

Got it. Does everything for quidel_covidtest get merged into that branch? I think I'm missing something about the automation processes.

[jingjtang]

@chinandrew quidel_covidtest is branch that is more up-to-date and is also the branch that is used for automation, can you merge this to that branch instead of main ?

Got it. Does everything for quidel_covidtest get merged into that branch? I think I'm missing something about the automation processes.

Yes, quidel_covidtest branch should be the most up-to-date one. The automation should be in deploy-quidel branch which is based on quidel_covidtest currently. When we have deletion support in the system, the automation will switch to run-quidel branch. And finally we will remove quidel_covidtest and quidel_flutest branches.

[chinandrew]

Does main not factor in at all? I though the deploy branches got main merged into them regularly.

[jingjtang]

Does main not factor in at all? I though the deploy branches got main merged into them regularly.

In my experience, at least not the case for ght (using run-ght) and quidel (currently using quidel_covidtest).

[chinandrew]

In my experience, at least not the case for ght (using run-ght) and quidel (currently using quidel_covidtest).

Interesting, thanks for explaining. @krivard how should we think about the version of quidel in main? Do we want to get them sync'd?

[krivard]

The workflow we had in mind with the current deployment system is broken, but looks like this:

• branch from main
• write some code
• PR into deploy-*
• PR deploy-* into main

This workflow is not usable with full-time developers who motor through fixes at the rate we currently do. We're currently using a modified workflow which is less broken, but far from ideal:

• branch from main
• write some code
• PR into main
• periodically PR main into deploy-*

Both workflows rely on main representing the currently deployed or imminently-deployed system. That is the only way we can be assured that bugfixes in the central utility library will get picked up by the individual indicators.

[chinandrew]

going to close this until we figure out branching