Add `first_activity` as a search filter option

[daveverwer]

First discussed in #3356 with additional context on Mastodon.

As suggested, we will add a first_activity search filter to limit package search to return any package where the first_commit_date matches the filter.

This will create a consistent UI for the search with first_activity and last_activity.

[daveverwer]

@DandyLyons I've just invited you to be a collaborator on the project. Creating a branch in the project directly means our CI can run on your code, where it does not for external forks.

Also, could you drop me a DM on Discord or an email to contact@swiftpackageindex.com so we can get a CLA in place for you.

Thanks for offering to implennt this!

[DandyLyons]

🙋🏼‍♂️ Dumb question. I don't know what CLA is.

[daveverwer]

🙋🏼‍♂️ Dumb question. I don't know what CLA is.

Not a dumb question at all! It's a Contributor License Agreement that we have for every contributor that just puts into writing some protections for the project. For example, that you have the right to contribute to an open source project without your employer coming to claim ownership on your code later. 😬

[DandyLyons]

Continuing from #3356 (comment) :

Design question: first "activity" vs. first "commit"

Computing a first activity similar to what we do for last activity (IIRC it's across PRs, issues) would be quite a bit more involved. I'm pretty sure we'd need to run additional Github graphQL queries to get the "head" of those stats (we currently only fetch the last few, again IIRC).

Sounds good. I'll go with first "commit" for now.

Yes, I think I'd also expect the first commit date as I'd expect it to be very unusual for there to be other GitHub activity like opening issues before at least an initial commit happens? Is that even possible?

Agreed, I wouldn't expect a first GitHub activity to happen before a first commit. But a scenario that might be fairly common is a package that has a first commit that was long before a first activity. For example with packages that started out as closed-source, and then transitioned to open-source. Still this probably isn't common nor a meaningful difference.

The only thing I'd add is that I think we should keep the syntax for the search as first_activity rather than call it first_commit. There is a potential to call it first_commit if we also want to add a last_commit, which would make sense, but honestly I think that's overkill.

Calling it first_activity rather than first_commit could be confusing to users and maintainers going forward. There are many examples of last_commit elsewhere in the codebase, and it could be quite confusing for "commit" to mean one thing in one context and another thing in another context.

As a user "first commit" is quite clear.

[daveverwer]

Calling it first_activity rather than first_commit could be confusing to users and maintainers going forward. There are many examples of last_commit elsewhere in the codebase, and it could be quite confusing for "commit" to mean one thing in one context and another thing in another context.

I’m sorry, but I’m afraid I don’t agree. There may be plenty of references to last_commit in the codebase, but they are not exposed to the end user.

The last_activity filter is the “field” name that we chose to represent a combination of a few dates. It is whichever date is most recent from the last commit date, the latest pull request activity date (opening, closing, or merging) and the latest issue activity date (opening or closing).

We determined that it’s very likely that the first commit will be the first “activity” in the project, and while in the first iteration of this feature, it won’t be an aggregate field and will purely be based on last_commit, I would like to keep the user experience consistent.

The alternative is that we implement both first_commit and last_commit to be based on commit dates and then have last_activity be the aggregate field, but I don’t like this approach. This is more functionality than people need, as people are not trying to find a specific package by commit date ignoring other activity on the project. They are looking for packages that have been “active” or not.

Looking at this from a user perspective, having first_commit and last_activity isn’t consistent.

I’d like to go with first_activity and last_activity if that’s OK.

[DandyLyons]

Sounds good. That’s the design I’ll use.