Date   

moderated Re: Site updates #changelog

Glenn Glazer
 

On 8/30/2019 21:13, Mark Fletcher wrote:

Changes to the site this week:

  • CHANGE: The email bounce returned when sending a message to a group you're not subscribed to had a link to the /join page, which if you are logged in, would bounce you to another page. Removed the /join part of the URL.
  • INTERNAL: Updated Facebook API integration to use their latest version.
  • API: Added googleloginstart and googleloginfinal endpoints.
  • API: Added facebookloginstart and facebookloginfinal endpoints.
  • NEW: Enterprise groups now support single sign-on (currently only by Auth0, others by request).
  • API: New logout endpoint.
  • API BREAKING CHANGE: All POST endpoints now require a csrf field. The new csrf_token in the login object should be used for this.
  • API BREAKING CHANGE: API endpoints have been moved to https://groups.io/api/v1. The old endpoints will remain up for a month.
  • API BREAKING CHANGE: The API is moving from Basic Authentication to a cookie based authentication. The existing Basic Auth tokens will continue to work until they expire.

Have a good weekend everyone.

Mark


I'm curious, Mark. Does the API have many programmatic clients outside of the groups.io infrastructure itself?

Best,

Glenn

--
We must work to make the Democratic Party the Marketplace of Ideas not the Marketplace of Favors.

Virus-free. www.avast.com


moderated Re: #hashtags

Chris Jones
 

On Sat, Aug 31, 2019 at 07:56 AM, Ken Kloeber wrote:
The question pertains to the topic here - revising subject lines  and how the result ends up getting threaded. That said I’m happy to cross post on gmf but I would have nothing of substance to add at this point. 
From my point of view this thread has generated more heat than light.

I have started a series of tests on Shal's test group and have found one "anomaly" (the quotation marks are important here) but until more has been done I will not report any detail back.

I reserve the right to report on GMF rather than here because I suspect that is the better place for it. I'll think a bit more about that...

Chris


locked Re: suggestion - Consistency (ies)

 

Ken,

"Messages", but "Posts by members"
What I've seen in Groups.io (I mean the interface, not user content) is that /message/ is the noun, and /post/ is the action.

"New Topic" and "Edit Topic", but we add a new (and edit an old)
"Subject"
A message has four key components: To, From, Subject, and body. In this context To is always the posting address of he group, and From is the email address of the person posting the message (possibly DMARC munged). When posting via the web UI the To and From are supplied implicitly, as is the Subject when using Reply rather than New Topic.

A /topic/ is a list of one or more messages where all but the first are replies to a message in that same topic, and all share the same Subject text.

... (typically better known as a "thread")
Whether to call them /topics/ or /threads/ was discussed long ago, with /topic/ winning out. Hopefully the UI and Help are consistent about that. I don't know if /threading/ (as in "the threading algorithm") is used anywhere in the UI or Help, but I would be ok with that as otherwise you need a circumlocution to avoid an abomination like "topicizing".

J wrote:
As in "all posts by this member". Good catch, I agree.
I agree, that nominialized use of /post/ is an example inconsistency in the UI. It could be rewritten as "All Messages By This Member".

If anyone spots other specific example inconsistencies posting them here may be a good way to get them corrected.

Shal


moderated Re: #hashtags

KWKloeber
 

On Fri, Aug 30, 2019 at 04:59 PM, Shal Farley wrote:
Ken,
 
Shal Farley wrote:
Ken,
Ok, but that doesn't explain why ...
 
If that page needs correction or improvement please do so (that's what wikis are for). Or let's discuss it in GMF.
 
Shal
******
shal I haven’t a clue about updating the page, or it’s incorrect at all. 
You referred me to that page in reply to my question why two subject lines, identical, would end up in different threads. 
Mid you know why I’m all ears. If you don’t i surely don’t either so can’t revise the wiki page. 

The question pertains to the topic here - revising subject lines  and how the result ends up getting threaded. That said I’m happy to cross post on gmf but I would have nothing of substance to add at this point. 
 


moderated Site updates #changelog

 

Changes to the site this week:

  • CHANGE: The email bounce returned when sending a message to a group you're not subscribed to had a link to the /join page, which if you are logged in, would bounce you to another page. Removed the /join part of the URL.
  • INTERNAL: Updated Facebook API integration to use their latest version.
  • API: Added googleloginstart and googleloginfinal endpoints.
  • API: Added facebookloginstart and facebookloginfinal endpoints.
  • NEW: Enterprise groups now support single sign-on (currently only by Auth0, others by request).
  • API: New logout endpoint.
  • API BREAKING CHANGE: All POST endpoints now require a csrf field. The new csrf_token in the login object should be used for this.
  • API BREAKING CHANGE: API endpoints have been moved to https://groups.io/api/v1. The old endpoints will remain up for a month.
  • API BREAKING CHANGE: The API is moving from Basic Authentication to a cookie based authentication. The existing Basic Auth tokens will continue to work until they expire.

Have a good weekend everyone.

Mark


moderated Re: Meta Suggestion: preferences

 

Funny about the food menu analogy. The best pizza place where I live (Berkeley) serves one kind of pizza each day and that’s it. The only choice you have to make is how many slices you want. (Also, one slice is really two there.:) 


On Aug 30, 2019, at 4:05 PM, Ken Kloeber via Groups.Io <KWKloeber@...> wrote:

On Fri, Aug 30, 2019 at 03:29 PM, Glenn Glazer wrote:
io can't be improved,
****
I didn't take Bob's comment that way at all -- just that gio is evolving and improving as it evolves  And sit back and enjoy the view..
I don't think that precludes developing excellent preferences about providing preferences, and I hope the range of available preferences do enlarge/become more ever more useful to all group users.  That said, as essentially an email exchange it may evolve to be the ultimate cat's meow, but as a pseudo forum I doubt it can reach a peer level with SimpleForum sites.

--
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


moderated Re: Meta Suggestion: preferences

KWKloeber
 

On Fri, Aug 30, 2019 at 03:29 PM, Glenn Glazer wrote:
io can't be improved,
****
I didn't take Bob's comment that way at all -- just that gio is evolving and improving as it evolves  And sit back and enjoy the view..
I don't think that precludes developing excellent preferences about providing preferences, and I hope the range of available preferences do enlarge/become more ever more useful to all group users.  That said, as essentially an email exchange it may evolve to be the ultimate cat's meow, but as a pseudo forum I doubt it can reach a peer level with SimpleForum sites.


moderated Re: #hashtags

 

Ken,

Shal Farley wrote:
Ken,
Ok, but that doesn't explain why ...

If that page needs correction or improvement please do so (that's what wikis are for). Or let's discuss it in GMF.
Shal


moderated Re: Meta Suggestion: preferences

KWKloeber
 

Glenn. I support multi preferences.  Or just ignoring/living with personal preferences/naming conventions, etc. 
But when the menu board says “flavors” but underneath it isn’t flavors, but sizes of all  flavors,
And it’s verboten to use “sizes” twice because it’s used elsewhere (above drink prices) basic confusion reigns ~insert pun~ “across the board.” 
 Or you use cup, and dish, and container for the same object, or quart or 4-cup for the same amount (am I getting 1x32oz or 4x8oz ??) Well the point is obvious. Multiflavorcornfuzion. 
Especially to the customer who is the one that it’s the first time trying to make sense of the menu and there’s 30 customers waiting behind. So s/he throws up the hands and walks out mumbling WTF under the breath. 
It all makes perfect sense to the person who put the board together but possibly not to the customer. 
Has anyone ever gone thru a KFC drive thru and was actually able to figure out the options?
All I want is chicken cuz I can’t eat mashed pots when I’m driving — not all this mishmash on the menu. “Oh we can do that, ask for just chicken
Arrrrrgh!


moderated Re: Meta Suggestion: preferences

 

Yeah but we’re just a bunch of users expressing our preferences, ranging from most naive to most sophisticated points of view (I don’t lump myself in with either of those). All kinds of features are suggested here, ranging from clearly insanely useful to iffy (with, of course, Mark being the arbiter). We are not designing “the preference system” here. We’re asking for features ranging fro sorely needed to pie-in-the-sky to generally-bad-idea-for the product. I’m sure you agree with me in general that not every feature suggested in this forum should just be implemented willy nilly, no matter how objectively helpful or dead-weight, and just made an option. And Mark clearly understands that as well, hence he picks and chooses. Discussions here are just that: discussions. We’re not in a design meeting. 😀


On Aug 30, 2019, at 12:27 PM, Glenn Glazer <glenn.glazer@...> wrote:

On 8/30/2019 11:50, J_Catlady wrote:
That’s great and I would generally agree. A lot of us here, like you, and including me, are (or were at some point) senior se’s and I’m sure you understand that it’s not always just “implement the feature, make it an option, and everybody’s happy.” You take the product as a whole into account. Any particular feature can possibly add or possibly detract from the product.

If that's true, then the preference system is not designed correctly. The whole point is that the product is a variable superset of user preferences, that setting a preference one way for one group does not affect the setting of the preference some other way by some other group. Thus "the product" is not affected as a whole other than to accommodate as many different styles as possible. If groups.io sets in stone some sort of preference, then it loses all of the groups who prefer the preference some other way. So insisting on some setting being some particular way does detract from the product by walling off a potential user base.

Best,

Glenn

--
We must work to make the Democratic Party the Marketplace of Ideas not the Marketplace of Favors.

Virus-free. www.avast.com

--
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


moderated Re: Meta Suggestion: preferences

Glenn Glazer
 

On 8/30/2019 12:19, Bob Bellizzi wrote:
Sit back for another year or so, enjoy the ride and you will see groups.io has no peer

Perhaps I am misreading this, but are you seriously suggesting that groups.io can't be improved? I agree that it is the best system out there, but anything can be made better, even the best thing available.

Best,

Glenn

--
We must work to make the Democratic Party the Marketplace of Ideas not the Marketplace of Favors.

Virus-free. www.avast.com


moderated Re: Meta Suggestion: preferences

Glenn Glazer
 

On 8/30/2019 11:50, J_Catlady wrote:
That’s great and I would generally agree. A lot of us here, like you, and including me, are (or were at some point) senior se’s and I’m sure you understand that it’s not always just “implement the feature, make it an option, and everybody’s happy.” You take the product as a whole into account. Any particular feature can possibly add or possibly detract from the product.

If that's true, then the preference system is not designed correctly. The whole point is that the product is a variable superset of user preferences, that setting a preference one way for one group does not affect the setting of the preference some other way by some other group. Thus "the product" is not affected as a whole other than to accommodate as many different styles as possible. If groups.io sets in stone some sort of preference, then it loses all of the groups who prefer the preference some other way. So insisting on some setting being some particular way does detract from the product by walling off a potential user base.

Best,

Glenn

--
We must work to make the Democratic Party the Marketplace of Ideas not the Marketplace of Favors.

Virus-free. www.avast.com


moderated Re: Meta Suggestion: preferences

Bob Bellizzi
 

Ditto what "J" Catlady said but add lots more years and experiences.
Sit back for another year or so, enjoy the ride and you will see groups.io has no peer
--

Bob Bellizzi


moderated Re: +Owner Email a Preference or a Permission?

 

But a decision still needs to be made about whether mods can choose, on their own, to receive (and/or send) owner messages. I was just pointing out a minor inconsistency with the way things work right now, regardless of what is decided. The fix is easy: change the log entry.


On Aug 30, 2019, at 12:14 PM, J_Catlady via Groups.Io <j.olivia.catlady@...> wrote:

You can call it a bug or an inconsistency. 😀


On Aug 30, 2019, at 12:07 PM, Gerald Boutin <groupsio@...> wrote:

On Fri, Aug 30, 2019 at 02:47 PM, J_Catlady wrote:
On Fri, Aug 30, 2019 at 10:38 AM, Gerald Boutin wrote:
One: the Permission - That allows the moderator ....
Two: The (Subscription) preference/setting that the Moderator has control of.
 
I wouldn't consider this an inconsistency.
No, it is an inconsistency. If something is a permission, I can't give it to myself. It must be given to me by someone higher up.

You would not call a variable that can be set by either the member or the owner (for example, a member's overall delivery preference) a "permission" just because someone higher than the member (a mod or owner) can set them.

This is just a slight inconsistency, but I think it does hint that during implementation, Mark had on one side of his mind the idea that this setting is actually a permission. Unfortunately, in another part of the implementation (the actual editing of the setting), it behaves as a preference rather than a permission.
 

 I thought we decided a while back that this was a bug, not an inconsistency.

eg) It should be working this way (but it isn't):

eg) Owner sets the permisison (P)
and the Moderator is given the option (O) to accept or not.

Result should be P "AND" O

In any case, it is what it is....

--
Gerald

--
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


--
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


moderated Re: +Owner Email a Preference or a Permission?

 

You can call it a bug or an inconsistency. 😀


On Aug 30, 2019, at 12:07 PM, Gerald Boutin <groupsio@...> wrote:

On Fri, Aug 30, 2019 at 02:47 PM, J_Catlady wrote:
On Fri, Aug 30, 2019 at 10:38 AM, Gerald Boutin wrote:
One: the Permission - That allows the moderator ....
Two: The (Subscription) preference/setting that the Moderator has control of.
 
I wouldn't consider this an inconsistency.
No, it is an inconsistency. If something is a permission, I can't give it to myself. It must be given to me by someone higher up.

You would not call a variable that can be set by either the member or the owner (for example, a member's overall delivery preference) a "permission" just because someone higher than the member (a mod or owner) can set them.

This is just a slight inconsistency, but I think it does hint that during implementation, Mark had on one side of his mind the idea that this setting is actually a permission. Unfortunately, in another part of the implementation (the actual editing of the setting), it behaves as a preference rather than a permission.
 

 I thought we decided a while back that this was a bug, not an inconsistency.

eg) It should be working this way (but it isn't):

eg) Owner sets the permisison (P)
and the Moderator is given the option (O) to accept or not.

Result should be P "AND" O

In any case, it is what it is....

--
Gerald

--
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


moderated Re: +Owner Email a Preference or a Permission?

Gerald Boutin <groupsio@...>
 

On Fri, Aug 30, 2019 at 02:47 PM, J_Catlady wrote:
On Fri, Aug 30, 2019 at 10:38 AM, Gerald Boutin wrote:
One: the Permission - That allows the moderator ....
Two: The (Subscription) preference/setting that the Moderator has control of.
 
I wouldn't consider this an inconsistency.
No, it is an inconsistency. If something is a permission, I can't give it to myself. It must be given to me by someone higher up.

You would not call a variable that can be set by either the member or the owner (for example, a member's overall delivery preference) a "permission" just because someone higher than the member (a mod or owner) can set them.

This is just a slight inconsistency, but I think it does hint that during implementation, Mark had on one side of his mind the idea that this setting is actually a permission. Unfortunately, in another part of the implementation (the actual editing of the setting), it behaves as a preference rather than a permission.
 

 I thought we decided a while back that this was a bug, not an inconsistency.

eg) It should be working this way (but it isn't):

eg) Owner sets the permisison (P)
and the Moderator is given the option (O) to accept or not.

Result should be P "AND" O

In any case, it is what it is....

--
Gerald


moderated Re: Meta Suggestion: preferences

 

That’s great and I would generally agree. A lot of us here, like you, and including me, are (or were at some point) senior se’s and I’m sure you understand that it’s not always just “implement the feature, make it an option, and everybody’s happy.” You take the product as a whole into account. Any particular feature can possibly add or possibly detract from the product. 


On Aug 30, 2019, at 11:24 AM, Glenn Glazer <glenn.glazer@...> wrote:

So, I've avoided a number of discussions here and on GMF because they seem to boil down to folks arguing about personal preferences of one sort or another.

I work as senior software engineer for a product that has complex server and client components, with an extraordinarily wide range of use cases. We get the chocolate versus vanilla discussions and customer requests all the time. When it comes to preferences and style, there is no one right answer that works for everyone. Welcome to the grand diversity of the human experience.

At work, if we permit a subjective feature in the first place, we enable a switch to turn it on and off or a slider if it isn't a binary. Those that want can have and those that don't aren't required to have it.

This approach completely walks around the whole problem of whether chocolate is "better" or "right" compared to vanilla and pleases the most number of people by stopping ourselves from saying OR when we could be saying BOTH.

Best,

Glenn
Who prefers French vanilla, but is okay with ice cream stores also carrying chocolate flavors.

--
We must work to make the Democratic Party the Marketplace of Ideas not the Marketplace of Favors.

Virus-free. www.avast.com

--
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


moderated Meta Suggestion: preferences

Glenn Glazer
 

So, I've avoided a number of discussions here and on GMF because they seem to boil down to folks arguing about personal preferences of one sort or another.

I work as senior software engineer for a product that has complex server and client components, with an extraordinarily wide range of use cases. We get the chocolate versus vanilla discussions and customer requests all the time. When it comes to preferences and style, there is no one right answer that works for everyone. Welcome to the grand diversity of the human experience.

At work, if we permit a subjective feature in the first place, we enable a switch to turn it on and off or a slider if it isn't a binary. Those that want can have and those that don't aren't required to have it.

This approach completely walks around the whole problem of whether chocolate is "better" or "right" compared to vanilla and pleases the most number of people by stopping ourselves from saying OR when we could be saying BOTH.

Best,

Glenn
Who prefers French vanilla, but is okay with ice cream stores also carrying chocolate flavors.

--
We must work to make the Democratic Party the Marketplace of Ideas not the Marketplace of Favors.

Virus-free. www.avast.com


moderated Re: #hashtags

KWKloeber
 

<<<On Thu, Aug 29, 2019 at 09:52 AM, Shal Farley wrote:
Ken,
Shal >>>
Ok, but that doesn't explain why
orig subj
orig subj
ended up in different threads/subjects/topics (take your pick <wink> )
They are identical.   
Might the algorithm be updated to also ignore other commonly used? like RE:; [SPAM] etc (mind has temporarily gone blank)--  that an email client or other might tack on to the subject line?


locked Re: suggestion - Consistency (ies)

KWKloeber
 

[avoding over quoting]  Shal, I get your point that's a matter of style, so there's no "rule" as you try to point to.  It's a matter of "direction."  Talking to the screen, the settings are "my" (mine) - I own them, I set them, I control them.  The screen talking back - they are "your"s  -- you own them, you set them - but I abide by them. I would say "you put on YOUR pants" but you would say I put on MY pants.

Note that the confusion complaints aren't by seasoned users that can go to plan B if a menu looks odd or doesn't supply the info or choices one expects,  We can click around and find what we want.  Put their shoes on -- It's those who are afraid that clicking something they aren't supposed to might blow up the world, or at least their laptop. 
Settings can occur in different areas.  Account settings, communication settings, display settings, bla bla.  But subscriptions is what I am subscribed to (a list of them where I can manage them?)  Now, if it were called This particular subscription's settings (opposed to another subscription's settings) then maybe novices could understand that better.  but "subscription" is confusing -- doesn't convey any readably recognizable context as to what comes next in the clicking order.  At least "Preferences" (display, communication, etc) would be recognizable.
But regardless, consistency is the key - when one goes from one screen to another or to a help page, there are different terms for the same items that a novice has to stop and wonder, what's the difference between a post and a message, or a subject and a topic or thread, or bla bla -- they're used interchangeably and I see their point that's it's just plain ol' confusing to them, so therefore frustrating, therefore avoided.