Eos: [PROJECT] [COMPLAINT] Abuse of Project Resources (Censorship)

[ghost]

Problem

• Several issues were closed far too fast, leading to additional problems for users (see #4839)
• Issues which ask for more transparency (team-overview) are closed, without any action: #4888
• Follow-up Issues which ask for team-overview (transparency) are closed with jokes, despite being assigned: #5003

Censorship

But Censorship crosses the line.

I insisted that issue #5302 is kept open, despite @jgiszczak closing it in https://github.com/EOSIO/eos/issues/5302#issuecomment-414501390 (as usual, far too fast, with totally unfounded justifications, at the cost of the user).

Due to my insistence, the bug was finally identified and fixed by a friendly person.

But a comment of mine (totally harmless) was deleted, see https://github.com/EOSIO/eos/issues/5302#event-1805754420

@EOSIO EOSIO deleted a comment from lazaridiscom 28 minutes ago

Without leaving any traces of who deleted the comment and why.

If i remind right, i wrote that both, the project-manager and @jgiszczak should revise their attitude towards users (and their issues).

This behavior (essentially of a single individual, who due to the missing team-overview has an unidentified role) is a shame for any project which advertises "next generation decentralization systems".

Contributions

Anyone can verify my contributions. It is crystal-clear that I do work for the benefit of EOS USERS and the project in general.

https://github.com/EOSIO/eos/issues?page=1&q=+author%3Alazaridiscom&utf8=%E2%9C%93

COMPLAINT

Censorship is an act of Barbarism.

I'm asking the Project-Lead to identify himself and to set strict policies which ~avoid~ ensure that similar incidents do not happen in future.

[jgiszczak]

Constructive comments are acceptable. Unconstructive complaints are not, and may be deleted.

[hokiecsgrad]

Hello @lazaridiscom,

Thank you for your concern. I have reviewed your post history for the EOS.IO project, and I can clearly tell that you're passionate about the program. The success of EOS.IO depends on a passionate community and dedicated users.

Please understand that @jgiszczak (and others) has been asked to take on the very difficult task of managing the incoming github tickets, and we have full faith and confidence in his decisions with respect to managing the many issues that come through the EOS.IO github site.

Regarding other questions you've brought up in the past, please know that we have many stakeholders and do our best to address all concerns from those stakeholders as appropriate. We may not respond to each and every concern, but they all factor into our decision making process. Thank you.

[ghost]

@hokiecsgrad , thank you for unlocking the issue.

The most important thing first:

you realize that there is an additional censorship within an issue about censorship?

EOSIO deleted a comment from MessyComposer an hour ago

No one should be allowed to delete comments. Readers have brains, they can judge themselves. Deleted comments make it impossible to see what really happened.

@MessyComposer

You can use additionally this resource here:

https://www.reddit.com/r/eos/comments/99qcs0/project_complaint_abuse_of_project_resources/

[ghost]

(I'll provide a full reply tomorrow, because this issue is an excellent starting-point for a policy document)

[heifner]

@MessyComposer @lazaridiscom expletives and name calling will not be allowed.

[ghost]

expletives and name calling will not be allowed.

I repeat: "Readers have brains, they can judge themselves. Deleted comments make it impossible to see what really happened."

I cannot judge if the censorship was justified, simply because the censorship removed the words (this is a classic dilemma, usually discussed by kids and not by mature IT professionals).

[NorseGaud]

Just wanted to state that I appreciate what @jgiszczak and @heifner are doing. It's not an easy job. Want to prevent the eosio Github managers from getting bitter and causing a ripple effect throughout the project. It usually takes one person in the right position and with the wrong attitude to take down an entire project. I've seen it 100 times. Anything I can do to help out, please let me know.

Also, have we thought about writing up a CONTRIBUTING and ISSUE document which clearly indicates the requirements and steps a user needs to take before they submit a pull request or issue?

[ghost]

@NorseGaud , I guess each and everyone appreciates what jgiszcak and heifner are doing, including me (well, with the exception of this "closing-issues-to-fast" and other "wild-west" stuff...).

As for an Issue template, see PR #5178 (closed a bit too fast) and follow-up issue #5321. CONTRIBUTING.md is a necessity, but depends to have policies etc. already in place.

[ghost]

@hokiecsgrad , why did you close this issue after writing your stuff? You really have to realize that this can be perceived as rudeness. It's like saying "I'm having the last say here, I don't care what you have to say, so I close now".

As for your comments, I'm unable to assess your statements fully, simply because I do not have all the relevant information. See this:

and we have full faith and confidence in his decisions with respect to managing the many issues

• who is "we"?
• who are you? what is your role? who pays you?
• As for your trust in jgiszcak: he messed it up, multiple times. And its essentially not his fault: the Project-Lead/Manager needs to provide policies, lets say the "wild-west-constraints".

In order to fix the situation, I suggest that you:

• [ ] Ensure that the Project-Manager identifies himself
• [ ] Provide a team-overview (nickname, role, employer)
• [ ] Provide a set of policies/procedures for member/collaborators/contributors (I guess that I should provide a draft, to ensure its user-centric)
• [ ] Ensure that the github repos reflect reality (many information/transparency can be given by standard github functionality).
  (list goes on...)

Example Policies / Procedures

For anyone with Issue-Tracker Access-Rights:

• If you are in deep coding-work, in bad mood etc., please stay away from the issue-tracker
• Ask the user to close the issue by himself, once he's satisfied with the response
• Ensure the the QA-team scans the issue for possible actions
• Follow the "Regression-Procedure" for issues which handle a regression.
• (...)

Passionate Stuff

My strengths lie within core-code, but I cannot work on a project which has organizational/transparency deficits. So trying to fix this first.

[heifner]

Our general approach is to close question issues and/or issues we believe are addressed. The submitter can create a new issue or ask for the closed issue to be re-opened if they feel their issue was not addressed. We currently have 585 issues and it is becoming increasingly difficult to keep up.

[NorseGaud]

Definitely looking forward to an ISSUE_TEMPLATE stating that issues are closed when they are believed to be completed in order to keep the issues queue as small as possible. (https://github.com/EOSIO/eos/pull/5321) I think that will solve a lot of the confusion people have.

[ghost]

Our general approach is to close question issues and/or issues we believe are addressed.

You should revise this approach. I have proven that closing issues too fast results in relevant action not being taken.

The submitter can create a new issue or ask for the closed issue to be re-opened if they feel their issue was not addressed.

This process is not acceptable. It introduces barriers and inconvenience for the users, it costs the users time, it produces additional noise and traffic on the issue-tracker.

See a comment within a relevant topic: https://github.com/isaacs/github/issues/583#issuecomment-245394377

There are (highly User-friendly) projects which ask users to close the issues themselves, once they think that their issue was solved.

We currently have 585 issues and it is becoming increasingly difficult to keep up.

A stricter project-organization can lead to less issues. And there are other methods to keep control over many issues, without loosing track of the real situation.