README: add info how to contact maintainers

[mkrainiuk]

Description

PR adds information to README about how to contact maintainers via github teams.

Fixes uxlfoundation/open-source-working-group#29 and fixes uxlfoundation/open-source-working-group#8

Checklist

All Submissions

• Do all unit tests pass locally? Attach a log. N/A, doc change
• Have you formatted the code using clang-format? N/A, doc change

[vbm23]

Hi Team,

I tried checking the Github Team Link as provided, though I get a 404 as it might have to do with access permission in the parent project as Rod is able to access the team link with an admin access.

@mkrainiuk can you help confirm?

Hence am not sure, if this would be a right way for public to reach out to project maintainers.

[mkrainiuk]

Hi Team,

I tried checking the Github Team Link as provided, though I get a 404 as it might have to do with access permission in the parent project as Rod is able to access the team link with an admin access.

@mkrainiuk can you help confirm?

Hence am not sure, if this would be a right way for public to reach out to project maintainers.

Oh, I didn't know the access to the team members could be limited, as a maintainer I have an access to all teams. In this case it's better to remove the links from the README, but I think we need the team names listed in README anyway so that users can tag a team instead of specific person (I mean the maintainers might change over time, but we can keep teams up-to-date).

[vbm23]

@mkrainiuk Agree on removal of links, though will suggest to use the Maintainers reference from oneDNN project uxlfoundation/open-source-working-group#9 covering details like role name, its description, its responsibilities, its requirements, its privileges, process of becoming that role along with contact details in a tabular fashion.

That would help address your below tickets
uxlfoundation/open-source-working-group#8
uxlfoundation/open-source-working-group#29
uxlfoundation/open-source-working-group#18
uxlfoundation/open-source-working-group#19

[mkrainiuk]

@vbm23 as I see oneDNN team uses specific user names, but I don't think it's a good idea since the names could change, so tagging the github team is more stable approach (e.g. instead of @mkrainiuk it should be @oneapi-src/onemkl-arch-write to discuss oneMKL architecture changes with all oneMKL architecture related maintainers). Could you please clarify why you think using teams is not a correct way to reach the maintainers?

But I agree that we need to extend the documentation about how to become part of one of the github teams.

[vbm23]

@mkrainiuk Agree on the names changing perhaps could also be applicable in maintaining the list of team members if any, though with reference to #18 expectation would be to define "Roles" within the project for example reviewer/code owner/maintainer who have certain responsibilities and all members of the same team may not have the equivalent responsibilities/privileges.

I see no harm keeping the Github Team though additional details perhaps alias contact/proxy emails details would also help to reach to them or something like that.

[mkrainiuk]

So what is left to do for oneMKL is adding some clarification about what responsibilities each oneMKL github team has, did I get that right? E.g. we plan to use domain specific teams as code owners who will be automatically assigned for PR reviews, so contributors don't need to guess who they should request review from.

But I planned to cover these changes as part of uxlfoundation/open-source-working-group#18 not by 8 and 29

[vbm23]

Agree @mkrainiuk & we can discuss more aspects of #18, once you start to work on it such as to cover Roles, Responsilitilites, Privileges, how to take up a role and so forth to provide the required transparency.