nathanshammah commented 4 years ago

This is a checklist of tasks to do before the repository becomes public. Some are proposals of things that could be implemented or improved and should be discussed, possibly here if on github, take them as ideas:

Needed for Launch

[x] check packaging tasks as per #230
[x] add syntax checks via black (#279)
[x] add CHANGELOG.md
[x] spruce up the README.md (#330 )
[x] enforce type hints via mypy (see also: #253)

Immediately after open-sourcing

[x] add code coverage (coveralls not free for private repos)
[x] trigger CI on all pushes (#316 )

Optional stuff:

[ ] consider using docker for CI even beyond PyQuil (In a python-only environment this may be an overkill, but certainly it makes everything robust)
[ ] have guides for contributors and maintainers and possibly autoreleases to pypi, test pypi.
[x] consider adding templates for PRs or issues: It would certainly help new contributors, may be cumbersome for UF team. In PRs, it could remind contributors to check code with black.=
[x] update the mitiq roadmap on the wiki, see #266

willzeng commented 4 years ago

Some comments:

asking folks to check code with black

What does this mean @nathanshammah ?

consider using docker for CI even beyond PyQuil (In a python-only environment this may be an overkill, but certainly it makes everything robust) consider adding templates for PRs or issues: It would certainly help new contributors, may be cumbersome for UF team.

These IMO are not needed for launch. They can be added later.

have guides for contributors and maintainers and possibly autoreleases to pypi, test pypi.

We have contributor guides already no? @karalekas How much work is it to set up the autoreleases?

nathanshammah commented 4 years ago

@willzeng edited that item to make it more clear: check code formatting with black or pycodestyle.

karalekas commented 4 years ago

@willzeng

setting up the autoreleases shouldn't take more than a couple of hours -- i'm happy to take that on
as for contributor guides, it's probably worth taking a day and combing through the various markdown files in the repo just to make sure they're updated to reflect the latest repo contents, install instructions, etc.
re: black / code style -- if we want to use this & enforce in the CI, id recommend doing so before external contributors come in. would only take an hour or so

karalekas commented 4 years ago

another potential checklist item: type checking with mypy. this is another code quality thing that can be enforced with CI, and is of course easier to implement the sooner you do it. my guess would be about half a day, only because I'd need to understand the QPROGRAM issue (#253)

karalekas commented 4 years ago

yet another potential checklist item: enforcing code coverage. this can be done using coveralls. we're currently at ~85%, and id bet we could get it over 90% in an hour

Name                                                    Stmts   Miss  Cover
---------------------------------------------------------------------------
mitiq/__init__.py                                           5      0   100%
mitiq/_about.py                                            24     11    54%
mitiq/_typing.py                                           10      2    80%
mitiq/_version.py                                           4      0   100%
mitiq/benchmarks/__init__.py                                0      0   100%
mitiq/benchmarks/maxcut.py                                 45      1    98%
mitiq/benchmarks/random_circuits.py                        44      2    95%
mitiq/benchmarks/randomized_benchmarking.py                20      1    95%
mitiq/benchmarks/tests/test_maxcut.py                      17      0   100%
mitiq/benchmarks/tests/test_random_circuit.py              31      0   100%
mitiq/benchmarks/tests/test_randomized_benchmaking.py      42      0   100%
mitiq/benchmarks/utils.py                                   8      0   100%
mitiq/factories.py                                        224     27    88%
mitiq/folding.py                                          236      8    97%
mitiq/mitiq_pyquil/__init__.py                              0      0   100%
mitiq/mitiq_pyquil/conversions.py                          12     12     0%
mitiq/mitiq_pyquil/pyquil_utils.py                         65     65     0%
mitiq/mitiq_pyquil/quil.py                                 63     63     0%
mitiq/mitiq_pyquil/tests/__init__.py                        0      0   100%
mitiq/mitiq_pyquil/tests/test_conversions.py                0      0   100%
mitiq/mitiq_pyquil/tests/test_quil.py                      23     23     0%
mitiq/mitiq_pyquil/tests/test_zne.py                       38     38     0%
mitiq/mitiq_qiskit/__init__.py                              2      0   100%
mitiq/mitiq_qiskit/conversions.py                          12      0   100%
mitiq/mitiq_qiskit/qiskit_utils.py                         32     19    41%
mitiq/tests/test_factories.py                             174      0   100%
mitiq/tests/test_folding.py                               552      0   100%
mitiq/tests/test_utils.py                                 110      0   100%
mitiq/tests/test_zne.py                                    39      3    92%
mitiq/utils.py                                             19      1    95%
mitiq/zne.py                                               26      0   100%
---------------------------------------------------------------------------
TOTAL                                                    1877    276    85%

karalekas commented 4 years ago

these two I think are definitely worth doing, even if you choose to pass for now on mypy / coverage stuff:

Move the changes.rst to the top-level directory and make it a markdown file. Having a markdown changelog and requiring contributors to add to it when opening a PR is a really great way to let release notes write themselves.
Clean up the README -- add some badges, add some color, add a code snippet w/ syntax highlighting, etc. Right now the main attraction is the source tree, which is not very exciting

nathanshammah commented 4 years ago

yet another potential checklist item: enforcing code coverage. this can be done using coveralls. we're currently at ~85%, and id bet we could get it over 90% in an hour

Name                                                    Stmts   Miss  Cover
---------------------------------------------------------------------------
mitiq/__init__.py                                           5      0   100%
mitiq/_about.py                                            24     11    54%
mitiq/_typing.py                                           10      2    80%
mitiq/_version.py                                           4      0   100%
mitiq/benchmarks/__init__.py                                0      0   100%
mitiq/benchmarks/maxcut.py                                 45      1    98%
mitiq/benchmarks/random_circuits.py                        44      2    95%
mitiq/benchmarks/randomized_benchmarking.py                20      1    95%
mitiq/benchmarks/tests/test_maxcut.py                      17      0   100%
mitiq/benchmarks/tests/test_random_circuit.py              31      0   100%
mitiq/benchmarks/tests/test_randomized_benchmaking.py      42      0   100%
mitiq/benchmarks/utils.py                                   8      0   100%
mitiq/factories.py                                        224     27    88%
mitiq/folding.py                                          236      8    97%
mitiq/mitiq_pyquil/__init__.py                              0      0   100%
mitiq/mitiq_pyquil/conversions.py                          12     12     0%
mitiq/mitiq_pyquil/pyquil_utils.py                         65     65     0%
mitiq/mitiq_pyquil/quil.py                                 63     63     0%
mitiq/mitiq_pyquil/tests/__init__.py                        0      0   100%
mitiq/mitiq_pyquil/tests/test_conversions.py                0      0   100%
mitiq/mitiq_pyquil/tests/test_quil.py                      23     23     0%
mitiq/mitiq_pyquil/tests/test_zne.py                       38     38     0%
mitiq/mitiq_qiskit/__init__.py                              2      0   100%
mitiq/mitiq_qiskit/conversions.py                          12      0   100%
mitiq/mitiq_qiskit/qiskit_utils.py                         32     19    41%
mitiq/tests/test_factories.py                             174      0   100%
mitiq/tests/test_folding.py                               552      0   100%
mitiq/tests/test_utils.py                                 110      0   100%
mitiq/tests/test_zne.py                                    39      3    92%
mitiq/utils.py                                             19      1    95%
mitiq/zne.py                                               26      0   100%
---------------------------------------------------------------------------
TOTAL                                                    1877    276    85%

@karalekas, about this: we had a discussion some time back (#122), and neither one of us seemed to know the difference between coveralls and pytest-cov. Are they just the same service, the former wrapped with APIs so that it shows up in the GH PR conversation, the latter more basic? The first one can be more helpful, the second one is less "intrusive". Personally, I am happy to go for it.

rmlarose commented 4 years ago

+1 for coverage and mypy.

willzeng commented 4 years ago

+1 for coverage and mypy

On Wed, Jul 29, 2020, 5:31 PM Ryan LaRose notifications@github.com wrote:

+1 for coverage and mypy.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/unitaryfund/mitiq/issues/268#issuecomment-665939605, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZDAS3UTGPSELCXLVD6HTR6CIMTANCNFSM4PKZQRLA .

karalekas commented 4 years ago

Added CHANGELOG.md and README.md bullets to the issue description, which we can discuss tomorrow @nathanshammah

karalekas commented 4 years ago

NB: Once we open-source the repo, we should drop the review-requested/assigned restriction on triggering the build.

willzeng commented 4 years ago

This is a good point. What should we replace it with? We’ll still want to be conservative about eating up too much of our cloud compute github time.

On Mon, Aug 3, 2020 at 13:10 Peter Karalekas notifications@github.com wrote:

NB: Once we open-source the repo, we should drop the review-requested/assigned restriction on triggering the build.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/unitaryfund/mitiq/issues/268#issuecomment-668137533, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZDAXNEJP6IRQ5HJ54XC3R63VRVANCNFSM4PKZQRLA .

-- https://unitary.fund/ Creating a quantum technology ecosystem that benefits the most people.

willzeng commented 4 years ago

@karalekas These are the current usage stats:

willzeng commented 4 years ago

316 checked a box here

willzeng commented 4 years ago

With #330 the needed parts for this issue are checked and so will close this issue

unitaryfund / mitiq

Checklist for public release of mitiq #268

316 checked a box here