I'm going to top post because your email is long and keeps repeating the
same things.
I'm not going to repeat myself other than to say this: Organisations are
made of humans, and humans are not software applications, closed source or
not. You will have better luck getting organisations to do things for you
if you display some empathy. Sometimes you can bully organisations into
doing things for you by causing a scene on social media. However, you
aren't always the always-right customer. You can't bully the ICTA into
writing reports for you by sending passive-aggressive emails to its
chairman. He's not going to get fired simply for ignoring rude emails.
On Thu, Feb 25, 2016 at 4:35 PM, Jules Mike Giovanni <johnally_at_eml.cc>
wrote:
> Hi Shane,
>
> Thank you for your opinion on the matter.
>
> (Every thing below is my personal point of view)
>
>
> This style of "questioning" works when discussing a piece of work, e.g.
> some code, or the wording of a standards document. It's effective when it
> is clear that we are objectively discussing "the work", and that the work
> is separate from "the person" who created the work. Comments in pull
> requests can appear brutal at first brush, but no one takes offence because
> of the context of the discussion. When I do code reviews, I take pains to
> emphasise that things should not be taken personally. It is human nature to
> make things personal!
>
>
> Is it really of your concern if things you say are taken personally?
> Should you really ensure that people do not take your code reviews
> personally or remedy to it? From my standpoint, people going as far as
> taking my code reviews personally shows a lack of professionalism. When
> about to step through a piece of code may it be from someone working for an
> enterprise or a college student, I try to be as objective and impartial as
> possible. I expect the author of the work to understand that beforehand and
> it is not of my responsibility to "sugar-coat" my code reviews to prevent
> such a thing as hypersensitiveness. Else, it will be a waste of resources
> and will counterfeit the doing such an activity (i.e code reviewing).
>
>
> If you actually want to get things done, you engage with Avinash
> privately, ask if you could have some of his precious time, maybe invite
> him for a cup of coffee and ask him how you can help. I'm sure that he
> would be delighted to talk about the activities of the group, the
> challenges that he's faced, and his plans and hopes for the coming year.
>
>
> This is a highly flawed approach. Placing someone out of his/her original
> environment in order to have an informal conversation with him/her does not
> ensure reliability of information. In other words, converting a formal
> approach to an informal approach and expecting a better flow of reliable
> information. Moreover, the information shared during that "private" session
> can never be used as evidence since the session is not documented. The
> moment you try to document such a session, you defeat your approach's
> purpose.
>
> Private radio stations are now hosting programmes where the public is
> allowed to express their concerns/questions/dilemmas. One of the most
> recurring concerns from members of the public is that they are being
> ignored. In many cases, there is no documented proof of it where they
> contacted an endpoint in an organisation and no answer or bogus information
> was given back. In essence, it is safe to assume that the channel of
> communication, in that context, was private and could possibly have started
> of with a friendly approach from that member of the public. Still, the end
> result was unsastifactory which brings us to the reason why these radio
> programmes exist. As per my understanding, they remove the private aspect
> of the communication and makes it public. Even these radio programmes face
> issues like bogus information or no response. However, in this case, there
> is a proof.
>
> Private session is only a way of building a personal relationship with
> someone for a specific goal (i.e information extraction). The grim side of
> it being it's a method to "trick" someone. I do understand you want make
> the respondant feel at ease by being in a safe environment but you are also
> sandboxing your conversation making it irrelevant to the public. Moreover,
> I don't fancy my chance of getting some "private" time with the ceo of a
> company, which service I'm paying for, just to get proofs that things are
> being done in my best interest. Neither do I want to "buy" that information
> from them because it would be a "corrupted" approach.
>
> Organsations to me are like closed-source applications. In all due
> respect, I absolutely don't care about the internals of them. I only expect
> an output to an input I give them. Some organisations do not have an
> endpoint to send that input to but that does not stop me from trying to do
> so and get an output. If ever I suspect the existence of a bug, I'll have
> to provide evidence of the input and the output I got. In retrospect to
> your suggestion of "private" sessions, this evidence does not exist as any
> information obtained cannot be verified (i.e the respondant can deny the
> information they gave out or simply deny the existence of such sessions).
> On the other hand, they can't deny the existence of an e-mail on a public
> mailing list. To add, it is risky to have a private conversation through
> e-mail and then make that public as it can create some privacy concerns
> (i.e arguing that such information was not meant to be disclosed). When
> implying that the conversation will be in a formal format and public (i.e
> cc'ing a public mailing list) is more beneficial on many level (as you saw)
> versus a friendly private conversation.
>
>
> Regards,
> Mike
>
>
>
> -- http://www.fastmail.com - Access all of your messages and folders
> wherever you are
>
>
Received on Thu Feb 25 2016 - 13:23:16 PST