Action (re)naming?

[Beanow]

@vsoch, I would like to come up with some names for the 2 actions we have.
As well as your thoughts on naming / renaming in general.

• sourcecred/sourcecred-action
• vsoch/cred-action

There's some risk we'll break (or rather, we will break) existing setups by moving/renaming, but I think we'll want to move vsoch/cred-action to the SourceCred org soon-ish? Might as well take the opportunity.

So before the move, it might be good to plan out names.

To get the ball rolling on that here's some thoughts, would like to hear yours!

---

I would say the use-case for vsoch/cred-action is to automate a full-blown SourceCred instance.
Including a static site with Cred scores. Soon to include Grain distributions. Potentially to include the SVG widget (if there's demand for it, though it needs some TLC to be v0.5.0 compatible).

While the use-case for sourcecred/sourcecred-action is to use SourceCred to generate the Cred scores, static site, widget. Primarily for insights, and on a Github repo. And have them displayed on that repository, rather than have that be a "SourceCred instance" in the sense that it uses all the features and has it's own repository to track that.

Although, to be specific. I think sourcecred/sourcecred-action is actually a set of GitHub workflow examples rather than a Github action right? We wouldn't break usage by renaming this, because the idea is you copy them.

---

So here's one option:

• vsoch/cred-action becomes sourcecred/github-action
  Because the org name will make it clear it's SourceCred. And this action will offer all the SourceCred features. So it's the action to reach for. The swiss army knife.
• sourcecred/sourcecred-action becomes sourcecred/github-workflow-examples
  I'll admit it doesn't have the best ring to it. But I think it would avoid confusion by being specific.

We could shorten those as sourcecred/action and sourcecred/workflow-examples resp. Though without context that could be misleading I feel. Especially "SourceCred workflow examples" could sounds like community guides on how to set up your social rituals to use SC or something along those lines.

Alternatively, if we wanted the action to have a bit more of a "first class" feel to it.
I think nothing beats sourcecred/sourcecred 😄
Practically however that means, implementing the action in the main repo.
Which comes with the extra work of fitting in with the dev process and goals for that repo.
And I'm worried that is more undue friction than it's worth.

[vsoch]

hey @Beanow ! Yes renaming is a given - and I anticipated doing this when the time is right to move over to sourcecred. Still in the queue to do are:

• merge and test @wchargin integration in Opening pull request to compare @wchargin changes #4
• implement the cache
• possibly Ability to discard commit history when pushing updates #10 if you think it's important

For each repository, I'll add my notes below.

Sourcecred Action

This repository was named as such originally because I had intended it to be "the sourcecred actions" and actually there is a bit of redundancy because it does provide templates for creating a contributors graphic OR a prototype, each via automated or pull request. The difference now is that these are just workflows that use the sourcecred container, and the action we are working on here is an official action (with Dockerfile and action.yml) that will be easier to use. With this in mind, I'm in support of renaming sourcecred/sourcecred-action to sourcecred/github-workflow-examples. I suspect we will eventually modify those recipes to use the action being developed here. For the rename I've opened a PR sourcecred/github-workflow-examples#42 along with an issue to do the eventual change to using the official actions sourcecred/github-workflow-examples#43.

vsoch/cred-action

As mentioned above, we would move this and rename at the same time, likely doing a PR to rename here first, then changing ownership. I would suggest a simpler name of:

• sourcecred/actions

because I don't see any other kind of actions that we might need to represent. If this case does happen, we would give the "other actions repos" some more specific name. I believe that repos named "actions" on GitHub would first be thought of as GitHub actions, so I think this repo gets priority. If we need another kind of actions repo, we can name accordingly (e.g., social-actions, pizza-actions, choose your action genre :))

As for another question of if we will support several kinds of actions, I think we should look into if it's still possible to use the folder substructure (as was possible for the early version of workflows). For example, the repo might be organized like:

└── contributor-graphic
    ├── action.yml
    └── Dockerfile
└── instance
    ├── action.yml
    ├── Dockerfile
    └── scripts

So then usage would be like:

    steps:
    - name: Generate SourceCred Prototype
      uses: sourcecred/actions/instance@v1.0.0

Another alternative to keep development separate / modular is to separate the repos and clearly distinguish the actions, eg.

sourcecred/prototype-action
sourcecred/graphic-action

And those could be plural depending on if we have subsets of more than one. What are your thoughts? I think my preference is (if it's possible) to develop actions together in subfolders of a single repository, so you / a developer / user always knows where to look. I definitely don't think actions should be tangled with the base sourcecred/sourcecred repository, that will become a hairball quite quickly.

[vsoch]

hey @Beanow ! Let me know when you want me to transfer the repo to sourcecred, and I'm happy to keep working on stuffs there! I'll let you take lead and no worries for time, I know you have a lot on your plate. :) Happy Thursday!

[Beanow]

Thanks! I think transferring it would break the existing usage right? My preference to move it would be when we're ready to dedicate time to maintain it. So that as we're breaking the now several users out there, we can support people with migrating and get to a v1 pretty soon.

For the moment I'm still on Initiatives, so we can address more of these Cred issues. This is pretty urgent to me, as it means we're not recognizing certain types of contributions.