Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get org members as authors, time-sort authors, sort tags to middle #2942

Merged
merged 2 commits into from
Dec 15, 2019

Conversation

HebaruSan
Copy link
Member

@HebaruSan HebaruSan commented Dec 13, 2019

Problems

In #2922 we enhanced Netkan to include owners of parent repositories in the authors list. This has two issues as pointed out by @Tekaoh:

  • Some GitHub repositories are owned by organizations rather than users, and currently they get added to author lists
  • Earlier maintainers (sometimes?) appear later in the list, but they should be earlier so it looks chronological

Also the tags property of .ckan files is not included in the property sorting transformer, so it defaults to the end. This isn't optimal.

Changes

  • Now we capture the owner.type property from the API and only add the repo owner to the authors list if it's User, otherwise we retrieve the members of the org and add them instead
  • Now as we traverse forks to earlier maintainers, we add them to the beginning of the list
  • Now the property sorting transformer is updated to put tags after resources, plus a few other minor personal preference tweaks

This will probably result in a lot of .ckans getting re-indexed, but that should be OK.

FYI to @Tekaoh, this is the pull request I mentioned.

@HebaruSan HebaruSan added Bug Something is not working as intended Easy This is easy to fix Pull request Netkan Issues affecting the netkan data labels Dec 13, 2019
@Tekaoh
Copy link

Tekaoh commented Dec 13, 2019

In the case of skipping an org, is there a way to check for public owners of an org? This would support situations where a new mod is only released on an org, with the owner of the org as the author. (This might be a pretty niche situation, but it's how I like to stay organized.)

@HebaruSan
Copy link
Member Author

HebaruSan commented Dec 13, 2019

Here's what GitHub is willing to tell us about your org:

So far I do not see a way to access the membership.

Here it is!

https://api.github.com/orgs/tekaohksp/public_members

I'll look into what we can do with that...

@Tekaoh
Copy link

Tekaoh commented Dec 13, 2019

Actually, I'm a little confused. In the case I commented on initially, the repo is currently in the org account, forked from mac's. Just two levels. I don't see how my Tekaoh name was included as the first entry... Must be coming from somewhere else already

@HebaruSan
Copy link
Member Author

The first user gets added from the metadata for the specific release that we're indexing, then we check the repo.

image

@HebaruSan HebaruSan added the In progress We're still working on this label Dec 13, 2019
@Tekaoh
Copy link

Tekaoh commented Dec 13, 2019

Oh, ok. That seems sufficient. I don't think it can ever be an org account that makes a release. So in the case of a new mod released in an org repo, the org name will be skipped and the actual user's name will come from the release.

For example, https://github.com/tekaohksp/Science-Full-Transmit would work that way and it would give the expected result.

@HebaruSan HebaruSan changed the title Skip org authors, time-sort authors, sort tags to middle Get org members as authors, time-sort authors, sort tags to middle Dec 13, 2019
@HebaruSan HebaruSan removed the In progress We're still working on this label Dec 13, 2019
@HebaruSan
Copy link
Member Author

HebaruSan commented Dec 13, 2019

Updated it to retrieve the org members. I wonder what that looks like for KSP-RO...

... it looks like this:

    "author": [
        "NathanKell",
        "SirKeplan",
        "StollD",
        "blowfishpro",
        "cherrydev",
        "pjf",
        "rsparkyc",
        "stratochief66",
        "zorg2044",
        "raidernick"
    ],

@DasSkelett
Copy link
Member

Earlier maintainers (sometimes?) appear later in the list, but they should be earlier so it looks chronological

Now as we traverse forks to earlier maintainers, we add them to the beginning of the list

Actually, I though this was intentional in the initial PR, and liked it that way.
IMHO the current maintainer should be first in the list. If someone tries to find out who to contact, he will likely start with the first name, and potentially raise an issue in a no longer maintained, outdated repository, forum thread, ... .

Yes we have a repository property in the metadata, but not every mod uses it, especially SpaceDock-hosted mods. And some users might ignore or not see it.

While it is very honourable to put the initial author in front of the list, in this case I would opt for usability/usefulness.

As of right now, it is reverse-chronological, which is also fine I think.

@HebaruSan
Copy link
Member Author

I though this was intentional in the initial PR

It wasn't. The manually-maintained author lists are in earliest-first order as far as I know, and during dev I was focused on the API logic and didn't consider the ordering. It's a HashSet anyway so the ordering may have been random?

@DasSkelett
Copy link
Member

It's a HashSet anyway so the ordering may have been random?

Oh well, it might have been pure coincidence for the 2 or 3 mods I tested then.

The manually-maintained author lists are in earliest-first order as far as I know

A quick look into some netkans reveals that this is indeed the case for the majority of the mods. I'm willing to go with the more or less established standard then.

Copy link
Member

@DasSkelett DasSkelett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prepare for another CKAN-meta commit flood!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something is not working as intended Easy This is easy to fix Netkan Issues affecting the netkan data
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants