Make email optional

[xaur]

Please make Politeia a real "first party" system.

I don't need email to use Decred network or participate in consensus voting, I don't need email to chat in Matrix, but I do need one to participate in Politeia.

As @sndurkin noted in chat:

if we're talking about a user who has lost access to his old email, tell him to create a new politeia acct

This logic applies to Pi account directly. I can take responsibility of not losing my Pi credentials, and pay for another account if I do.

I have no resources to run my own email server and really control my account. This means I'm stuck with 3rd party email.

It's funny that 3rd party email provider has more control over my Pi account than my Pi private key.

Sorry about the tone, I'm just super upset about this requirement.

[xaur]

Related: #544 (2FA support).

[xaur]

To reformulate: Stakeholders should not be required to have email to participate in governance discussions.

Also, imagine what happens if Pi is compromised and the database of stakeholder email addresses is leaked, along with Decred addresses they used to pay fees.

[lukebp]

Blocked by #860.

[lukebp]

Closing this issue due to inactivity or because it was included in the v1.0.0. If you feel this issue is still relevant, please re-open it to bring it to our attention.

[xaur]

@lukebp still relevant and even mentioned in the proposal. Please reopen, I don't have the perms.

[lukebp]

An issue for this will be opened as part of the new roadmap once the pi proposal passes.

[xaur]

I noticed that sometimes new issues are created even when there are existing issues for same change. In my view it is unnecessary because all the discussion and linking in the original issue gets forgotten. What is the motivation to re-create them?

[lukebp]

To keep the workspace clean and the team focused on actionable items. Having pages of old issues is like having boxes of old files all over a workplace. Its a distraction. Most of the dicussions are also outdated by the time the issue becomes relevant. Opening new issues as they become actionable allows you to discuss the issue using the full breadth of information that is available at the time of its implementation.

[xaur]

Thanks for sharing your logic. Looks like mine is very different and I don't quite follow the organizational style of this issue tracker.

An issue for this will be opened as part of the new roadmap once the pi proposal passes.

Problems with this workflow:

• Making email optional is a relevant and desired feature and I've seen no disagreement here. This is independent of the proposal. The proposal can fund and accelerate some features ofc but projects and proposals are different entities with a possible many-to-many relationship.
• Opening new issues leads to duplication and loss of knowledge.
• When you need to #link something, it is confusing to have multiple issues for same thing.
• If a good idea was shared in issue #X, you'll have to quote it link #X in #Y anyway.
• Mass-closing legit feature requests like this is a slightly demotivating factor.

keep the workspace clean and the team focused on actionable items

This is critical and I try to achieve this too. But I would implement it differently than closing/duplicating issues.

In issue trackers this is commonly solved by issue metadata and filters, i.e. attaching/removing labels and bookmarking search queries using those labels and/or keywords. On GitHub you can also try project boards with rich features to show only relevant issues and organize them in 2D space. You can check how godcr or dcrdex used those.

Most of the dicussions are also outdated by the time the issue becomes relevant.

I agree this can happen but I see things getting lost/forgotten more often than outdated comments becoming a problem.

In case of this #554, the arguments made in the first 3 comments and all the accumulated linking will hold and stay relevant even if you create a new issue.

Same for previous cases. All the details outlined in #591 were still relevant when #825 was created for same thing, they are still relevant today 2.5 years later, yet that brainwork is now pushed into the archive. #843 was "got rid of" by redirecting to some long design repo issue, yet it was "rediscovered" almost 1 year later in #1425 when someone else encountered it. #865 was closed as duplicate of #1124 while the opposite was true. #746 was closed as "duplicate" because it was "buried", while #1035 was the real duplicate.

Opening new issues as they become actionable allows you to discuss the issue using the full breadth of information that is available at the time of its implementation.

This reads like the opposite is true - the discussion will start from scratch and participants will need to recollect past discussions and link to them. The loss of context is amplified if most discussions and desicions are made outside the issue tracker (which is the case for Politeia).

Mind that I don't write it all up to annoy you. Politeia's approach to issue tracking is so different from many projects I've seen and participated in. I think issue tracking processes developed in software over the decades solved real problems and are worth reusing to improve productivity for all parties and stimulate more contributions.

Updated 2021-06-10 to list more problems with the current workflow and examples of closing past stuff which is still relevant.