Create individual plans to discuss

[abelsiqueira]

Spawned from standup.

Each one creates a plan (answering the issues) and we discuss approaches in the meeting.

[abelsiqueira]

We can disagree with the issues or come up with our own issues.

[abelsiqueira]

Relevant issues:

• https://github.com/NLeSC/generalization/issues/83#issuecomment-1022242856
• https://github.com/citation-file-format/cffconvert-github-action/issues/60#issuecomment-1021186016

[abelsiqueira]

cc @fdiblen @jspaaks

[fdiblen]

My proposal (WIP)

1. Decide which repositories we want to do that We already have requirements for filtering Start with NLeSC repositories first then outside of NLeSC
2. Decide at what level we want to do automation I think
   • what ever tool we develop it should only filter the repositories based on our requirements
   • it should not create GH issues or PRs
   • would be nice, but not required:
     • if it can provide some statistics
     • if it is re-usable
3. A tool for automatic filtering
   • Check for existing solutions. Is GitHub interface good enough? If we really need to build something new:
     • It should be simple and reusable
     • preferably a shell script or Python script
     • keeping statistics (via cron job) for NLeSC may be useful:
     • how many repos with CITATION.cff?
     • how many repos are using our GA?
4. Agree on the text for the GH issue and use the same text
5. Agree on the text for the PR and use the same text
6. Create some test repositories to test our filtering method
7. Decide what NLeSC repositories we will start with, create separate issues for bookkeeping and assign to our selves to the issues
8. Decide how everyone will follow the interactions, how/who will react to questions etc.
9. Decide what repos are interesting outside of NLeSC and work on them

[abelsiqueira]

Abel's Plan

Overview:

• Download meta information in whatever way we can already filtering CITATION.cff.
• Create automated filters
  • based on meta information;
  • based on files and their contents (might involve cloning).
• Evaluate the number and quality of the results and reassess plan.
• Find ~5 people that we know that will be affected and asked that they think of the plan.
• Evaluate and reassess.
• Create sorting criteria.
• Create issue template.
• Create PR template.
• for case in ["5 people above", "NLeSC RSEs", "Filtered"]
  • Send automated issues.
  • If the user reply with [send me a pr], we send an automated PR.
  • Handle other cases manually.
  • Evaluate and reassess.

Details

• x: decide on language

  Julia with GitHub.jl. I like Julia and I have used GitHub.jl before. It can access cffconvert as a Python package, and as a shell command. Cons: first time usage for colleagues. GitHub.jl doesn't cover search.

• x: decide on what to automate

  See #16

• x: Write the text of the issue

• x: decide on input/output for the filters

  I think it depends on the size of the initial body of work, but I would prefer to have an auxiliary function to read and write to file, and read and return internal objects (arrays of dictionaries?) for speed.

• Split into filtering function for reusability and script

  Many of the filters are useful for other CFF bot applications, such as

  • Finding invalid CITATION.cff
  • Updating the action version
  • Analytics

Filters

Agree

• x: Add functionality to filter based on presence of a CITATION.cff file
• x: Add functionality to filter based on CITATION.cff occurring in the root of the repo
• x: Add functionality to filter on valid CITATION.cff
• x: Add functionality to filter on whether the repo already uses workflows
• x: Add functionality to filter based on whether the repo already uses Pull Requests
• x: Add functionality to filter based on whether the repo already uses a validator
• x: Add functionality to filter based on whitelist of repos

Comment

• x: Add functionality to filter based on whether the repo accepts external PRs

  It would be ideal, but can it be done automatically?

• x: Add functionality to filter based on whether we already sent a similar PR previously

  I would not worry at first.

• x: Add functionality to filter based on whether the repo's CITATION.cff has seen multiple updates

  Could be a sorting criteria, instead of filter.

Sorting

This is a multicriteria situtation, so we need to handle with care, instead of simply piping sorting functions.

• Number of stars
• Number of contributors

[abelsiqueira]

We decided on the following plan:

• initial set of URLs curl https://research-software.nl/api/software_cache | jq '.[] | .repositoryURLs.github[]' --raw-output > urls.txt
• pure filtering in node
• verify that the repo has a CITATION.cff in the root
• results in a list of candidate repos; inspect the list by hand
• iterate the steps, include additional filters
• once we're happy with the curated list of repos, manually create issues said repos