Please remove the requirement to share private email addresses.

[epoberezkin]

You don't need them.

[matchboxbananasynergy]

I'll wait for @lberrymage to fully weigh in on this, but this seems like the bare minimum required.

If you, as a developer, upload an update that for whatever reason (such as a new sensitive permission) requires a review and it is not clear to the reviewer why it was added, how else are they meant to reach out for clarification?

If an app that has been uploaded is about to be delisted due to falling behind in its targetSdk, how is the developer meant to be warned?

You could argue that in your case, assuming this is about uploading SimpleX Chat, someone could open an issue on the public tracker about this, but that doesn't sound like the best practice for 2 reasons:

1. Not every app uploaded is going to have a public tracker
2. The conversation about this might not be best made public

[matchboxbananasynergy]

To expand on this, I don't really see a viable path that doesn't require a contact e-mail of some sort.

An alternative path that could be viable would be to remove the e-mail from this GitHub prompt and instead add a mandatory e-mail field in Parcelo when uploading (or updating, for existing devs that wouldn't have provided it through Parcelo yet) instead. This would allow the flexibility of providing a more generic e-mail instead, rather than the one for the GitHub account, but it's also important for the provided e-mail to be one that the developer/project actually checks, as the communication for Accrescent might concern the app's removal from the store, so it's a balance...

[lberrymage]

@epoberezkin A contact email is required for developer console accounts, and this is unlikely to change. However, you are correct that this doesn't necessarily require access to GitHub emails. Once an email verification system is implemented, this requirement can be removed, and developers will be able to use an email address of their choosing.

[epoberezkin]

We publish the app on F-Droid, we communicate with F-Droid maintainers via their Gitlab and our GitHub issues - the email was never requested.

if you don’t recognise GitHub as an identity provider and don’t plan to communicate via GitHub, then there is no real reason to offer GitHub authentication - just ask to register with email and password.

You can’t really declare that you adhere to privacy principles, and then ask two forms of identification just to review the app registration process.

[epoberezkin]

The same happened with many other repositories btw - flathub, AppImage - they accept pull requests as a registration and at no point asked to create accounts, leave alone asking for email address.

[lberrymage]

This is because we run very differently than these repositories. We manage a server which will include a stable API for DevOps automation; changing app security, privacy, and quality policies which developers will need to keep up with; notifications for when developer action is required, review pass/fails, and when publishing succeeds. All of these require an automated notification system, and email is ubiquitous for this.

We intentionally don't collect any more information than is needed of developers to verify they're authorized to publish their apps and to properly operate the service (send them notifications). There are also plans to add other forms of authentication including generic email/password in the future to allow more privacy and security for those that want it: see #478.

GitHub authentication was easy to implement and covers most people's needs, which is why it was implemented first.

@epoberezkin, the email you use with your github account is already public knowledge anyway.
https://www.iana.org/assignments/uri-schemes/prov/simplex

[epoberezkin]

@ghost making email public and allowing service communication via this email is not the same.