moderated Beta Group Guidelines #meta


Bruce Bowman
 

In the interest of being more proactive, may I suggest:
  • Expected behavior for posting to the beta group be included in its guidelines
  • These guidelines be posted to the group once a month.
Thanks,
Bruce


Glenn Glazer
 

I'm perfectly fine with leaving it informally in Mark's judgement with occasional remarks.

Best,

Glenn

On 05/26/2021 09:01, Bruce Bowman wrote:
In the interest of being more proactive, may I suggest:
  • Expected behavior for posting to the beta group be included in its guidelines
  • These guidelines be posted to the group once a month.
Thanks,
Bruce


--
#calcare
PG&E Delenda Est


Duane
 

On Wed, May 26, 2021 at 01:15 PM, Glenn Glazer wrote:
I'm perfectly fine with leaving it informally in Mark's judgement with occasional remarks.
As a group, most of us probably are.  Having the Guidelines (with a bit of clarification on some points) posted would be considerate of the new members joining and/or those that didn't see (or remember) his previous comments.

Duane


Glenn Glazer
 

On 05/26/2021 11:46, Duane wrote:
On Wed, May 26, 2021 at 01:15 PM, Glenn Glazer wrote:
I'm perfectly fine with leaving it informally in Mark's judgement with occasional remarks.
As a group, most of us probably are.  Having the Guidelines (with a bit of clarification on some points) posted would be considerate of the new members joining and/or those that didn't see (or remember) his previous comments.

Duane

I'm okay with that. No so much a fan of the monthly drumbeat.

Best,

Glenn

--
#calcare
PG&E Delenda Est


KWKloeber
 

Bruce

This would be a helpful reminder.  Casting adide one of my long-ago suggested rules (a #Suggestion is not an open microphone to begin a popularity poll nor for piling on "Me toos",) "I agree" (darn, that's hard to avoid.)
How about we generate a list and have MF bless it (that is, in the positive sense -- not in the south-of-the-Mason-Dixon-Line meaning)?

-ken


Bruce Bowman
 

If Group Guidelines do not exist for this purpose, what purpose do they serve?

It just seems unreasonable to ask people to adhere to expectations that have been expressed nowhere but in some long-forgotten email. I actually tried to search for it but came up empty.

Regards,
Bruce


 

Here's one suggested one, which Mark (for obvious reasons;) sometimes gently reminds me offlist about: Try to consolidate your messages about one topic rather than send multiple messages. I fervently hope this will be my only message in this topic. I've so far tried to get by on Likes.
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


KWKloeber
 

Bruce Bowman wrote:
I actually tried to search for it but came up empty.

Hey Bruce

If you can't define it, you can't enforce it.  If you can't measure it, you cant fix it.

Here is a prior msg to Mark (just copied verbatim so forgive my not fine-tuning it) when we had been discussing the "new" beta group back in Jan 2020.  Could we use this as a jumping-off point for interested-others to add to and suggest guidelines to Mark he could fine tune to whatever will help him the most?

Will you be publishing guidelines - specifically referring to what is most helpful to you and want to see added (or refrained from) re: discussion of a #suggestion.  Some thoughts if you decide to go that route:

- "I agree" and "me too" be forever banned (unless Beta is intended to be a popularity poll.)  "LIKE" works.

- "No one will use that" -  no one has enough foresight to definitively predict what the average user (or non-average) will or will -

- "That would cause a mess" or "cause more confusion than now" or "can't be implemented"  or ..... similar type replies.  

- For the most part "opinions" have little value and add to unnecessary chaff on Beta.  Everyone has one and every one (just as everyone) is as valid as another.

- "Fact-based" -  discussions/additions/clarifications that are fact-based and add to understanding or clarification (or forbid improvement) of someone else's suggestion, not leading to needing to defend one's opinions (rather than presenting or clarifying facts,) which adds tons of chaff. 

....more..?    Thx


 

Hi All,

I think augmenting the group guidelines is a good idea, and I'd appreciate help with that. What I want is beta to be an inclusive, welcoming group where people can propose new ideas without fear of being attacked or shot down. To quote noted philosopher Bill S. Preston, Esquire, "be excellent to each other."

Thanks,
Mark
(who is on vacation until Tuesday)


 

Ok, so one more message from me in this topic, given Mark's request:

Mark, I like your previously mentioned exhortations not to shoot down ideas without an affirmative reason that they are bad or might actually hurt something or be bad for the product. What gets my goat are messages that say, "Why do we really need this? You can just do [xyz inconvenient workaround]." There are almost always workarounds. Heck, there's a workaround to groups.io! Why do we need it? Just create your own email list!

The answer to those kinds of comments is always the same: "Yes, there's a workaround, but we are just trying to make things better, make mods' and members' lives easier than having to do the workaround, and the suggestion doesn't hurt anything." It's like rinse-and-repeat.

I think arguments against a suggestion are fine if they describe why they could actually have a negative effect.

And I have one more pet-peeve subservient to this: "I'm not arguing against this" followed by the above ("but we don't really need it" yada yada).
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


KWKloeber
 

On Fri, May 28, 2021 at 11:09 AM, J_Catlady wrote:
You can just do [xyz inconvenient workaround].
Toward cutting off such replies before they occur, it might be helpful if the original #suggester was as complete as humanly possible in the original po,t  i.e., *I realize we can work around this by... but the downside is....* or whatever.  There's no way to know if the #suggester is even aware there's a workaround, so oftentimes we ass/u/me s/he doesn't know. -- #suggesters,  put yourself in your recipients' shoes.
  
It may also be helpful to succinctly explain why a #suggestion is made.  Just posting *I #suggest xyz* gives MF no clue as to the utility of doing that, or what the problem is leaving it where is it.  *Here's why #suggestion would be better ....* gives everyone involved more information.
We might think we shouldn't need to explain our "whys and wherefores" but in the long game it can make life easier.  We aren't making suggestions to only MF (otherwise this group isn't needed -- it could be via email,) we're doing it for discussion.  i.e., if we don't need *some point* discussed then it's critical to provide enough information to demonstrate that *the point* doesn't NEED to be discussed - i.e., that the #suggester has already considered it.

just 0.02, unsure how to succinct it into a guideline.


 

On Fri, May 28, 2021 at 11:03 AM, KWKloeber wrote:
unsure how to succinct it into a guideline
"If you make a suggestion, please motivate the suggestion: include the reason why it would be useful and/or the problem it solves; any use cases you know exist, or that may exist; and current workarounds you are aware of and why you think they are insufficient or could stand improvement."
 
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu


Marv Waschke
 

I was a development manager for large software projects for many years and I designed and implemented several defect/enhancement tracking systems. Here are my suggestions, which are not original. Some of them have been mentioned before, all are commonplace among development managers.

  • One issue per thread. Don't add new issues to existing threads. Think hard before piling additional features onto others suggestions.
  • Keep in mind three general classes of issue and try to make clear where your issue fits when you post it.
    • Defects. The system is performing contrary to specification, documentation, or reasonable expectation. Remember that what one person sees as a reasonable expectation, another person may see as an enhancement.
    • Design flaws. The system is performing to specification, but the spec is inconsistent or fails to comply with the overall design and intent of the system.
    • Design enhancements. Suggestions for improving the system.
  • Describe the issue in a way that makes it reproducible. Just saying that something is wrong without describing exactly how to make it happen is worse than useless to developers because they waste time guessing how to reproduce the problem, and often end up fixing the wrong issue. Don't report an issue until you have figured out how to make it happen again. When describing enhancements, describe the results you want. Resist the temptation to tell the developer what to do rather than the result you want. Let them figure out how to implement a solution. They know more about the system works than you do, but they don't know how you use it or want to use it.
  • Developers have to decide what to work on next. Help them by explaining how urgent or important the issue is. How often does the issue appear in your group or groups? When it does appear, how disruptive is it in real terms? Not how angry or upset people are, but how are they materially affected? Are all groups subject to the disruption, or does some special characteristic of your group make it vulnerable? If you are upset about an issue, wait until you have calmed down to report. The system has been working for years. The sky won't fall if you wait a day or two.
In general, this is a well-intentioned and polite group. For me, keeping it that way is guideline number one!
Best, Marv


Glenn Glazer
 

On 05/29/2021 12:22, Marv Waschke wrote:
In general, this is a well-intentioned and polite group. For me, keeping it that way is guideline number one!

THIS.

I'm fairly agnostic to what the group rules are or will be, but I object to hardline enforcement techniques.  I feel they stifle conversation and actually make things less polite or at least, less respectful of contributors.

Best,

Glenn

--
#calcare
PG&E Delenda Est


Duane
 

On Sat, May 29, 2021 at 03:15 PM, Glenn Glazer wrote:
I'm fairly agnostic to what the group rules are or will be, but I object to hardline enforcement techniques. 
It's Mark's group (as well as his site), so it's up to him how 'hard' any enforcement should be or is.  I know in the past he has warned some people, then moderated them, then I believe he banned them (but only he knows for sure.)  If he does publish guidelines, we have the choice of accepting them in order to post or of not posting, same as with any group.

Duane


Glenn Glazer
 

On 05/29/2021 14:46, Duane wrote:
It's Mark's group (as well as his site), so it's up to him how 'hard' any enforcement should be or is. 

Yes, of course. But he also asked for our thoughts, so I gave mine.

Best,

Glenn

--
#calcare
PG&E Delenda Est


KWKloeber
 

Adding to list below:

- It likely would be helpful to cut down on unnecessary chafe in replies by avoiding reminding us that "it's Mark's business" or that  "Mark can implement a #Suggestion (or not) as he sees fit," or that "Mark can decide whether a #Suggestion will benefit enough members," and so on and so forth. 
It's intuitively obvious that Mark can do whatever he wants - we neither need to be reminded nor do we need to remind others.


Here is a prior msg to Mark (just copied verbatim so forgive my not fine-tuning it) when we had been discussing the "new" beta group back in Jan 2020.  Could we use this as a jumping-off point for interested-others to add to and suggest guidelines to Mark he could fine tune to whatever will help him the most?

Will you be publishing guidelines - specifically referring to what is most helpful to you and want to see added (or refrained from) re: discussion of a #suggestion.  Some thoughts if you decide to go that route:

- "I agree" and "me too" be forever banned (unless Beta is intended to be a popularity poll.)  "LIKE" works.

- "No one will use that" -  no one has enough foresight to definitively predict what the average user (or non-average) will or will -

- "That would cause a mess" or "cause more confusion than now" or "can't be implemented"  or ..... similar type replies.  

- For the most part "opinions" have little value and add to unnecessary chaff on Beta.  Everyone has one and every one (just as everyone) is as valid as another.

- "Fact-based" -  discussions/additions/clarifications that are fact-based and add to understanding or clarification (or forbid improvement) of someone else's suggestion, not leading to needing to defend one's opinions (rather than presenting or clarifying facts,) which adds tons of chaff. 


Glenn Glazer
 

On 05/31/2021 21:21, KWKloeber via groups.io wrote:

Adding to list below:

- It likely would be helpful to cut down on unnecessary chafe in replies by avoiding reminding us that "it's Mark's business" or that  "Mark can implement a #Suggestion (or not) as he sees fit," or that "Mark can decide whether a #Suggestion will benefit enough members," and so on and so forth. 
It's intuitively obvious that Mark can do whatever he wants - we neither need to be reminded nor do we need to remind others.


I have most often seen this as a response to criticism. If we cut down on that, I think much of this sort of comment will be unnecessary.


Here is a prior msg to Mark (just copied verbatim so forgive my not fine-tuning it) when we had been discussing the "new" beta group back in Jan 2020.  Could we use this as a jumping-off point for interested-others to add to and suggest guidelines to Mark he could fine tune to whatever will help him the most?

Will you be publishing guidelines - specifically referring to what is most helpful to you and want to see added (or refrained from) re: discussion of a #suggestion.  Some thoughts if you decide to go that route:

- "I agree" and "me too" be forever banned (unless Beta is intended to be a popularity poll.)  "LIKE" works.

Like does not work in email in either direction: I cannot like a post by email and I do not see likes in my email. I for one, almost never use the web interface and I do not believe I am unique in this.

- "No one will use that" -  no one has enough foresight to definitively predict what the average user (or non-average) will or will -

- "That would cause a mess" or "cause more confusion than now" or "can't be implemented"  or ..... similar type replies.  

- For the most part "opinions" have little value and add to unnecessary chaff on Beta.  Everyone has one and every one (just as everyone) is as valid as another.

- "Fact-based" -  discussions/additions/clarifications that are fact-based and add to understanding or clarification (or forbid improvement) of someone else's suggestion, not leading to needing to defend one's opinions (rather than presenting or clarifying facts,) which adds tons of chaff.

The rest of these seem good.

Best,

Glenn


--
#calcare
PG&E Delenda Est


Andy Wedge
 

On Tue, Jun 1, 2021 at 06:26 AM, Glenn Glazer wrote:
Like does not work in email in either direction: I cannot like a post by email and I do not see likes in my email.
If you reply to a post by email and just put +1 as your message text, it will be recorded as a Like. You cannot see Likes unless you use the Web UI though.

Andy


Glenn Glazer
 

On 05/31/2021 23:15, Andy Wedge wrote:
On Tue, Jun 1, 2021 at 06:26 AM, Glenn Glazer wrote:
Like does not work in email in either direction: I cannot like a post by email and I do not see likes in my email.
If you reply to a post by email and just put +1 as your message text, it will be recorded as a Like. You cannot see Likes unless you use the Web UI though.

Andy

Oh, thanks. I didn't know that. TIL.

Best,

Glenn

--
#calcare
PG&E Delenda Est