# Contributing metrics **URL:** \ **Category:** Survey Strategy\ **Tags:** sims-maf\ **Created:** [October 29, 2021, 7:07pm UTC](https://www.rubin.community/t/contributing-metrics/6010 "2021-10-29T19:07:18Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![ljones](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/ljones/32/1804_2.png) [@ljones](https://www.rubin.community/u/ljones)\ **Post date:** [October 29, 2021, 7:07pm UTC](https://www.rubin.community/t/contributing-metrics/6010/1 "2021-10-29T19:07:18Z")
Hi all, I know many people are working on metrics and we appreciate this hard work! To contribute these metrics into MAF to be run as part of our standard processing please read further. Metrics need to be runnable within MAF, as part of rubin\_sim. This means we both need it to match our API (see the [tutorial](https://github.com/lsst/rubin_sim_notebooks/blob/main/maf/tutorial/02_Writing_Metrics.ipynb)) and we need the actual code. Once your metric is runnable within MAF, the process to actually get us the code is to create a PR (Pull Request) to add it into [rubin\_sim](https://github.com/lsst/rubin_sim). This means: create a fork of rubin\_sim, add your metric to your fork (in the maf/metrics or maf/maf\_contrib directories), and then issue a PR from your fork to merge it back into lsst/rubin\_sim. I would like to also request a couple of additional considerations: - Please do match our API. The [tutorial](https://github.com/lsst/rubin_sim_notebooks/blob/main/maf/tutorial/02_Writing_Metrics.ipynb) can help explain what we’re looking for in a “Metric” code object, and this [workbook](https://github.com/lsst/rubin_sim_notebooks/blob/main/maf/science/NewMetricWorkbook.ipynb) notebook can help you test and build your own metric. - If your software requires additional software packages for dependencies, please make a note of this in the PR. Because we don’t automatically install all of the dependencies on (e.g.) DataLab, missing dependencies can cause imports of rubin\_sim to fail. Until we get these additional software dependencies installed (and installable automatically, in a future update for rubin\_sim), the best work-around is to import these new dependencies _inside_ the metric class itself, instead of at the top of your file. That way, the dependency will only be searched for if someone is trying to use your metric, instead of when it’s imported. Here is an example: `import george` is hidden inside a metric class [StaticProbesFoMSummaryMetric](https://github.com/lsst/rubin_sim/blob/88eb4e9dc8e6f1e4519627b02d2bc9ff267183af/rubin_sim/maf/maf_contrib/static_probes_fom_summary_metric.py#L327). - Please add some documentation to your metric. - A docstring in the code is very useful – see this [time domain challenge metric example](https://github.com/lsst/rubin_sim/blob/88eb4e9dc8e6f1e4519627b02d2bc9ff267183af/rubin_sim/maf/metrics/season_metrics.py#L168) – and will show up in [the documentation](https://rubin-sim.lsst.io/maf-api-metrics.html#rubin_sim.maf.metrics.TdcMetric). - A notebook demonstrating the use of the metric, together with more background information about its usefulness or limitations is helpful. These will go into [rubin\_sim\_notebooks](https://github.com/lsst/rubin_sim_notebooks). - If you go the extra step of adding a unit test for your metric, we will really appreciate it! The bonus here is if we need to reconfigure something in your metric or something elsewhere changes (maybe your software dependency changes their API), we can much more easily diagnose and fix the problem without having to come ask you to do it for us. Here is an example of a [unit test for some metrics](https://github.com/lsst/rubin_sim/blob/main/tests/maf/test_technicalmetrics.py). This works best if you explore a couple of cases where you might expect to get different answers. Thank you and we really appreciate your work on metrics! We do really want to gather up as many of the community metrics as possible, particularly those which feature in cadence notes or white papers. When we generate new survey simulations, being able to run these metrics and test the effects of the survey strategy variations immediately is immensely helpful. If you have any questions or need help with this process, please do feel free to reach out - either here on [community.lsst.org](http://community.lsst.org) or on the #sims-maf slack channel is preferred. Lynne ---
**Author:** ![ljones](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/ljones/32/1804_2.png) [@ljones](https://www.rubin.community/u/ljones)\ **Post date:** [March 17, 2024, 12:06am UTC](https://www.rubin.community/t/contributing-metrics/6010/2 "2024-03-17T00:06:59Z")
I’ve just updated the links above, so that they should work again. We moved to snake case and updated the tutorials, but hadn’t realized they had been linked here.