Date   

moderated Re: Guidelines tab

 

Mark,

Yes, great. But although we can then send a link to the wiki page to (a) new members and (b) people who need a reminder, sending the link is unhelpful to people who only use email and never log in. If at least new members could also be emailed the text automatically (in addition to sending automatically to everyone once a month), that would be a great boon. So would adding the ability to send it individually on demand.

Also, I would like the auto-email to go out as a special notice,

Thanks!

J

Sent from my iPhone

On Aug 30, 2017, at 3:04 PM, Mark Fletcher <markf@corp.groups.io> wrote:

Hi All,

Thanks for the feedback. Shal, I understand your proposal, but it definitely implies a level of complexity, both in terms of UI and implementation. I do like the flexibility of utilizing the calendar for sending out notices, but a lot of the feedback I've received over the years is that it's not intuitive.

It seems like if there's an option to send out the guidelines page once a month automatically, that maybe that takes care of the majority of what people want in terms of an automatic notice system?

So, modified proposal:

- Designate a wiki page as a guidelines page
- There'd also be a checkbox to indicate that this page should be emailed out once a month to everyone except people on No Mail.
- I'd also add additional visibility/permissions options for every wiki page, so that moderators could hide pages from subscribers.

Make sense?

Thanks,
Mark

On Tue, Aug 29, 2017 at 7:09 PM, Shal Farley <shals2nd@...> wrote:
Jeremy,

> Over all groups, I suspect there are some using the wiki for their
> own, 'random', purposes, within which group guidelines (and such)
> would not fit.

True.

Such a group can create its own "home" page for the wiki, to replace the automatic index page that is there by default. That's what I've done in mine. The group's wiki home page only links to the pages that are appropriate to the group's use of the wiki;  the guidelines (and sticky) pages don't show up except in the full list of pages (which I don't expect most members to ever peruse).

> ... but separate control setting, perhaps with more restrictions on
> visibility and editability, ...

That's on my wish list for the wiki generally. There is already a per-page "mods-only may edit" control, but I'd also like to be able to control visibility on a per-page basis (mods-only, members-only, members and parent-group members only, public).

Shal

--
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum





--
J

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated Re: Integration of Sub-Groups #suggestion

 

Hi Brian,

On Tue, Aug 29, 2017 at 8:35 PM, Brian Vogel <britechguy@...> wrote:

          Amen!   I have been saying that subgroups as implemented and presented by groups.io are dead zones for a long while now.  They are used on other forums and are presented such that members of the main group are aware that the subgroups exist.  And even subgroups can have subgroups, but at all levels the subgroups are visible at the level of the group that serves as the parent group.  That way you know they're there and, by their names, what their purpose is.


Are you asking for something other than the 'combined' view that Jeremy is asking for? IIRC, you previously asked for subgroup names to be displayed at the top of the page? I'm not sure how that would work for groups with lots of subgroups (some have 10-50).

Thanks,
Mark 


moderated Re: Integration of Sub-Groups #suggestion

 

Hi Jeremy,

Thanks for the feedback. I definitely appreciate it. I'm always looking for ways of improving the service. Comments inline.


On Tue, Aug 29, 2017 at 6:19 PM, Jeremy Harrison via Groups.Io <jeremygharrison@...> wrote:

The starting point is perhaps one of conception: that sub-groups are essentially normal, stand alone, groups except for their designation as sub-groups, and having membership restricted to that of the main group, functioning as a separate group just for that sub set; with the main group being where most things happen. A better conception might be that the main group is just a base or shell, for a number of sub-groups, with no more than an owner, the master member list, some settings and a home page: all the activity and resources happening within the sub-groups; with perhaps one being a regarded as the primary sub-group (first among equals), sharing the master member list, but quite possibly with little or no activity.

I don't understand the purpose of forcing the parent group to be a shell, with no activity. What advantage does that provide? One thing to keep in mind with any proposal is the lifecycle of groups. Generally they start as a stand-alone group, and then they decide they want subgroups. The stand-alone group becomes the parent group. How would your proposal affect that?

Members of the main group, apart from being part of the primary sub-group, should then be able to join other sub-groups, as now, with moderatorship being set separately for each sub-group. Whether ownership, or any moderating privilege, should cascade down to sub-groups, and how this might work is something for debate: there is certainly a case that each sub-group should have its own owners and moderators, with those of the main group not necessarily being even members. Different groups will have different wants and priorities in this area, with many issues of balancing power and responsibility to be faced and resolved. I can certainly foresee a need for sub-groups management (creation and deletion) privilege to be subject to approval (‘You can set up, and become owner of a sub-group, subject to my approval of each sub-group – and it’s then all down to you’).

Subgroups already have complete moderator/owner controls. How would this be different?

 

Then there should be – essentially – a three layer perspective over membership, as far as each sub-group is concerned: someone can be a member of that sub-group; a member of the main group (but not that sub group); or a total-non-member (even of the main group, with only public rights). All ‘who can do (or see) what’ settings should then be based on this, with extension as now to cover moderators, etc. So something (whatever: messages, posting, files, etc.) should be available to public, main group members, sub-group members or (sub group) moderators.

If I understand this correctly, that's already how things work.
 

Within the web interface, then I think there need essentially to be two views – at ‘main group’ and sub-group level; with the ‘main-group’ view showing a composite of all subscribed sub-group bits (messages, files, calendar entries, etc.). I’m not sure quite how this should work – whether there should be a separate ‘main group’ view set of pages, in addition to sub-group ones, or whether should be some sort of switch to change from main to sub group view. Perhaps a drop down menu at the top of all pages, to select the main, overall, view, or any subscribed sub-group view. On the home page (or pages), perhaps group descriptions for both main and (current) sub-group; with a list of all subscribed sub-groups, and all those available to join (as made visible), with a note of those requiring authorisation. But anyhow, it should be as easy to move from the same page for different sub-groups, as for different pages for the same sub-group.

What you're asking for is a new view, or new set of views, that aggregate all subgroups that you're subscribed to? So, the Messages tab would show all messages from all subgroups that you're a member of, for example? If you just go to https://groups.io and click the Messages or Calendar tabs, right now you get that for all the groups you're a member of. These new views would be like that, but only for the subgroups you're a member of?

 

One further aspect of integration that I feel desirable is to be able to set ‘to (specified) other sub-group’ as a default, or selectable, option – on its own or in conjunction with other options (group, sender, moderators).

Not sure I understand this part. Can you explain further? 

Thanks!
Mark


moderated Re: Guidelines tab

 

Hi All,

Thanks for the feedback. Shal, I understand your proposal, but it definitely implies a level of complexity, both in terms of UI and implementation. I do like the flexibility of utilizing the calendar for sending out notices, but a lot of the feedback I've received over the years is that it's not intuitive.

It seems like if there's an option to send out the guidelines page once a month automatically, that maybe that takes care of the majority of what people want in terms of an automatic notice system?

So, modified proposal:

- Designate a wiki page as a guidelines page
- There'd also be a checkbox to indicate that this page should be emailed out once a month to everyone except people on No Mail.
- I'd also add additional visibility/permissions options for every wiki page, so that moderators could hide pages from subscribers.

Make sense?

Thanks,
Mark

On Tue, Aug 29, 2017 at 7:09 PM, Shal Farley <shals2nd@...> wrote:
Jeremy,

> Over all groups, I suspect there are some using the wiki for their
> own, 'random', purposes, within which group guidelines (and such)
> would not fit.

True.

Such a group can create its own "home" page for the wiki, to replace the automatic index page that is there by default. That's what I've done in mine. The group's wiki home page only links to the pages that are appropriate to the group's use of the wiki;  the guidelines (and sticky) pages don't show up except in the full list of pages (which I don't expect most members to ever peruse).

> ... but separate control setting, perhaps with more restrictions on
> visibility and editability, ...

That's on my wish list for the wiki generally. There is already a per-page "mods-only may edit" control, but I'd also like to be able to control visibility on a per-page basis (mods-only, members-only, members and parent-group members only, public).

Shal

--
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum





moderated Rearrange photos in an album / nested albums #suggestion

Sara <gigideeagostina@...>
 

In the photos section, I would like to be able to:

1. Rearrange photos in a photo album. 
2. Mass edit photo names
3. Define which photo is the album thumbnail
4. See the entire photo in thumbnail, or get to pick what the thumbnails show (as it is always something awkward, like their elbow or their face cut off)
5. Created nested/sub album folders


Thank you!

Sara


moderated Re: notification re cancelled invite if recipient attempts to respond #suggestion

Sarah k Alawami
 

I agree there. I thought logically there would have ben, but can this be looked into?

Rank: high
Priority: high

On Aug 29, 2017, at 9:41 PM, J_Catlady <j.olivia.catlady@...> wrote:

I was testing cancelling an invitation. It turns out that if someone responds by email to an invitation (i.e., attempts to accept the invitation) but the invitation has been cancelled, they receive no notice of this, not even a bounced email. I think there should be something to communicate to them that the invitation has "expired" or whatever.
--
J
 

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu



moderated notification re cancelled invite if recipient attempts to respond #suggestion

 

I was testing cancelling an invitation. It turns out that if someone responds by email to an invitation (i.e., attempts to accept the invitation) but the invitation has been cancelled, they receive no notice of this, not even a bounced email. I think there should be something to communicate to them that the invitation has "expired" or whatever.
--
J

 

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated Re: Integration of Sub-Groups #suggestion

Brian Vogel <britechguy@...>
 

Jeremy,

          Amen!   I have been saying that subgroups as implemented and presented by groups.io are dead zones for a long while now.  They are used on other forums and are presented such that members of the main group are aware that the subgroups exist.  And even subgroups can have subgroups, but at all levels the subgroups are visible at the level of the group that serves as the parent group.  That way you know they're there and, by their names, what their purpose is.

--
Brian  - Windows 10 Home, 64-Bit, Version 1703, Build 15063  (dot level on request - it changes too often to keep in signature)
I worry a lot. . . I worry that no matter how cynical you become it's never enough to keep up.
    ~ Trudy, in Jane Wagner's 
            Search for Signs of Intelligent Life in the Universe


moderated Re: Guidelines tab

 

Jeremy,

Over all groups, I suspect there are some using the wiki for their
own, 'random', purposes, within which group guidelines (and such)
would not fit.
True.

Such a group can create its own "home" page for the wiki, to replace the automatic index page that is there by default. That's what I've done in mine. The group's wiki home page only links to the pages that are appropriate to the group's use of the wiki; the guidelines (and sticky) pages don't show up except in the full list of pages (which I don't expect most members to ever peruse).

... but separate control setting, perhaps with more restrictions on
visibility and editability, ...
That's on my wish list for the wiki generally. There is already a per-page "mods-only may edit" control, but I'd also like to be able to control visibility on a per-page basis (mods-only, members-only, members and parent-group members only, public).

Shal

--
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum


moderated Re: Integration of Sub-Groups #suggestion

 

On Tue, Aug 29, 2017 at 06:19 pm, Jeremy Harrison wrote:
In looking into sub-groups, as a newcomer to Groups.io, a major issue that strikes me about them is that they are very poorly integrated with their main group
That problem struck me early on - or at least, the ways in which they *are* integrated seem random or undocumented, and so their behavior seems unpredictable. Unlike you, though, instead of taking the time to think about and analyze the situation, I've just stayed away from using subgroups. Hopefully your message will help speed up getting them better designed, and then, maybe, at some distant day in the future, I will start using them.:)
 
--
J

 

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated Integration of Sub-Groups #suggestion

Jeremy H
 

In looking into sub-groups, as a newcomer to Groups.io, a major issue that strikes me about them is that they are very poorly integrated with their main group, and each other, and that many of the issues that have been raised in other threads are a result, or a reflection, of this. My apologies if this post is felt to be rather long, or cover old ground, but it is an attempt to indicate all the areas where I consider integration needs to be improved, to enable them to be tackled together, or as part of an overall plan, rather than raising and resolving half issues as they arise.

The starting point is perhaps one of conception: that sub-groups are essentially normal, stand alone, groups except for their designation as sub-groups, and having membership restricted to that of the main group, functioning as a separate group just for that sub set; with the main group being where most things happen. A better conception might be that the main group is just a base or shell, for a number of sub-groups, with no more than an owner, the master member list, some settings and a home page: all the activity and resources happening within the sub-groups; with perhaps one being a regarded as the primary sub-group (first among equals), sharing the master member list, but quite possibly with little or no activity.

Members of the main group, apart from being part of the primary sub-group, should then be able to join other sub-groups, as now, with moderatorship being set separately for each sub-group. Whether ownership, or any moderating privilege, should cascade down to sub-groups, and how this might work is something for debate: there is certainly a case that each sub-group should have its own owners and moderators, with those of the main group not necessarily being even members. Different groups will have different wants and priorities in this area, with many issues of balancing power and responsibility to be faced and resolved. I can certainly foresee a need for sub-groups management (creation and deletion) privilege to be subject to approval (‘You can set up, and become owner of a sub-group, subject to my approval of each sub-group – and it’s then all down to you’).

Then there should be – essentially – a three layer perspective over membership, as far as each sub-group is concerned: someone can be a member of that sub-group; a member of the main group (but not that sub group); or a total-non-member (even of the main group, with only public rights). All ‘who can do (or see) what’ settings should then be based on this, with extension as now to cover moderators, etc. So something (whatever: messages, posting, files, etc.) should be available to public, main group members, sub-group members or (sub group) moderators.

Within the web interface, then I think there need essentially to be two views – at ‘main group’ and sub-group level; with the ‘main-group’ view showing a composite of all subscribed sub-group bits (messages, files, calendar entries, etc.). I’m not sure quite how this should work – whether there should be a separate ‘main group’ view set of pages, in addition to sub-group ones, or whether should be some sort of switch to change from main to sub group view. Perhaps a drop down menu at the top of all pages, to select the main, overall, view, or any subscribed sub-group view. On the home page (or pages), perhaps group descriptions for both main and (current) sub-group; with a list of all subscribed sub-groups, and all those available to join (as made visible), with a note of those requiring authorisation. But anyhow, it should be as easy to move from the same page for different sub-groups, as for different pages for the same sub-group.

Something that is probably desirable, but hard, if not impossible, to achieve, is the ability to share some entities (such as files or photos) between specified (but not all) sub-groups, either as a whole, or at folder/album level.

One further aspect of integration that I feel desirable is to be able to set ‘to (specified) other sub-group’ as a default, or selectable, option – on its own or in conjunction with other options (group, sender, moderators).

And then perhaps issues over group management, of less importance: the ability to copy settings from one sub-group to another, make all members of one sub-group members of another, or perhaps change primary sub-group.

Quite how things might work or be set up in practice will be down to technical considerations, and the way each group chooses to function.

Jeremy


moderated Updates to Trello

main@beta.groups.io Integration <main@...>
 

[Beta] New card "Updating all events of a repeating event can cause earlier events to disappear." was added to list "Bugs".


[Beta] The red label "Bug" was added to the card "Updating all events of a repeating event can cause earlier events to disappear.".


[Beta] The description of card "Updating all events of a repeating event can cause earlier events to disappear." was changed to:

Create a repeating event. Then, edit an instance of that event, but not the original/earliest one. Then select that you wish to update all events for that repeating event. Event instances earlier than the one you edited will disappear.


[Beta] New comment on card "Updating all events of a repeating event can cause earlier events to disappear." by Mark Fletcher:

This is because we delete all single event instances and regenerate them. But the repeat event object has the newer date/time. We need to see if the person has changed the date/time of the event in question. If not, then we don't modify the repeat event object's date/time. If yes, then we do not give the user the option to modify all events for the repeating event.


moderated Re: Guidelines tab

Jeremy H
 

Getting back to Mark's proposal, while I like the basic principle, I'm not sure how happy I am with just using a page from the normal wiki. Over all groups, I suspect there are some using the wiki for their own, 'random', purposes, within which group guidelines (and such) would not fit.

Possibly the answer would be to have a second wiki - with the same editing facilities, etc., but separate control setting, perhaps with more restrictions on visibility and editability, as a wiki for the group per se, rather than the subject of the group: whose pages can be stuck in various places (as 'Sticky Wickis' not only for messages, but Photos, Files, etc.), displayed on a separate guidelines tab (just one?, or several? - if, this as separate tabs, or with a drop down menu?), or pulled out (manually or automatically) for use in messages, calendar entries, etc. Essentially, a second wheel of an existing type, rather then a brand new one. 

Jeremy


moderated Re: Guidelines tab

 

On Tue, Aug 29, 2017 at 12:33 pm, Shal Farley wrote:
You create a monthly recurring event, and insert that page into it's description.
I see the problem. I wouldn't do that. It again creates the problem of multiple instances of duplicate text that have to be maintained. I wouldn't use the calendar for this anyway. My idea was that the text appears in one place, and one place only, and anything else that uses it just uses pointers. So you only have to maintain one thing. Your idea to insert that text at the moment of sending for real-time messages seems ok on the surface. But I am instinctively against using the calendar for sending monthly messages anyway. I think Mark is re-thinking the whole issue of "scheduling files" but I'd have to look back at that thread to remind myself.
 
--
J

 

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated Re: Guidelines tab

 

J,

I'm not sure I understand the problem. Why and how could it go out
any earlier than that anyway, assuming you're making the changes
between scheduled dates?
Here's the scenario:

1) You create a guidelines page
2) You create a monthly recurring event, and insert that page into it's description.
3) At the next month the event text is posted to the group.
4) You correct a typo in the guidelines page.
5) At the next month the event text is posted to the group.

The question is whether the correction you made at (4) is in the next posting (5).

I think you would want it to be, but a simple-minded implementation of the Insert Page function would have copied the text as it was when you created/edited the event at time (2). In effect this would defeat our purpose. Instead I think the Insert Page would have to put a placeholder into the event description, so that at time (5) the event is posted using the updated page content from (4).

I'm not using the calendar for anything, since I haven't needed
it) so I may be missing something.
The key understanding is that an event in the calender can optionally cause a notice and/or reminders to be posted to the group, as a message to the group members. The notice/reminders appear in the group's Messages section just like any other. A notice is sent at the time of the event, reminders are sent at selected times in advance of the event.

And in fact my idea is to make this function separate from the
calendar anyway...???
I understand.

My thought is that the ability to schedule things to happen at future dates is functionality that is already present in the Calendar, so an enhancement to that capability seems to me more logical conceptually - where else do you look for things that have been scheduled than in a calendar? - and simpler to implement, than creating that functionality separately in features like the Wiki.

Shal

--
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum


moderated "date joined" now displays "date applied," should display "date accepted" #suggestion

 

I often want to see the date/time that someone became a bona fide member of the group. But the "date joined" now shows the date they applied, not the date their membership request was accepted. Could this be changed?
--
J

 

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated Re: Guidelines tab

 

On Tue, Aug 29, 2017 at 11:00 am, Shal Farley wrote:
What if the message formatting toolbar, in both ad-hoc messages to members and Event descriptions, had an "Insert Page" function? ... Not as a link to the Wiki page, but insert a copy of the page's text.
I like this idea but haven't thought through possible ramifications.

if you edit the wiki page I think you'd want the updated text to go out in the next month's notice.
I'm not sure I understand the problem. Why and how could it go out any earlier than that anyway, assuming you're making the changes between scheduled dates? But then, I don't use the calendar for this now (in fact, I'm not using the calendar for anything, since I haven't needed it) so I may be missing something. And in fact my idea is to make this function separate from the calendar anyway...???
 
--
J

 

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated Re: Guidelines tab

 

J,

Another helpful thing would be the ability to easily resend the the
guidelines message to any member at any time - they might request
them, they might need a reminder, etc. This would be for members who
don't access the group via the web.
...
I forgot to add that being able to *automatically* send it
out monthly to the entire group is very important to me.
What if the message formatting toolbar, in both ad-hoc messages to members and Event descriptions, had an "Insert Page" function? This would bring up a selection dialog to pick a wiki page, and would insert that wiki page into the body of the message. Not as a link to the Wiki page, but insert a copy of the page's text.

I think that would go a long way to solving the "maintain multiple copies of the same text" problem. You could even insert the page after a customized greeting/introduction and/or before a customized signature for that message.

With scheduled messages (repeating events) it would be a bit more tricky. For one thing I think you'd want the insertion to be deferred until the message is sent. That is, if you edit the wiki page I think you'd want the updated text to go out in the next month's notice.

For another:

I'm currently kludging this by hand every month because I don't like
the calendar's "event" terminology.
By itself, the Insert Page idea wouldn't solve that problem. But maybe it could work in conjunction with an event option that turns off the event boilerplate and uses only the Description text.

Shal

--
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum


moderated Re: Guidelines tab

 

Oh, good idea!
J

Sent from my iPhone

On Aug 29, 2017, at 10:25 AM, Joseph Lee <joseph.lee22590@...> wrote:

Hi,

Similar to groupname+help address, something like groupname+guidelines address that people can emails to and receive guidelines in reply.

Cheers,

Joseph

 

From: main@beta.groups.io [mailto:main@beta.groups.io] On Behalf Of J_Catlady
Sent: Tuesday, August 29, 2017 10:01 AM
To: main@beta.groups.io
Subject: Re: [beta] Guidelines tab

 

What do you mean by "a new email address"? I'm thinking of an "action" from the member page to "resend group guidelines"

 

J

 

On Tue, Aug 29, 2017 at 9:55 AM, Joseph Lee <joseph.lee22590@...> wrote:

Hi,

I second the below suggestion, possibly with a new email address that sends a copy of the guidelines page to members.

Cheers,

Joseph

 

From: main@beta.groups.io [mailto:main@beta.groups.io] On Behalf Of J_Catlady
Sent: Tuesday, August 29, 2017 9:53 AM
To: main@beta.groups.io
Subject: Re: [beta] Guidelines tab

 

p.s. Another helpful thing would be the ability to easily resend the the guidelines message to any member at any time - they might request them, they might need a reminder, etc. This would be for members who don't access the group via the web.
--
J

 

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu

 


--
J

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


--
J

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated Re: Guidelines tab

 

Hi,

Similar to groupname+help address, something like groupname+guidelines address that people can emails to and receive guidelines in reply.

Cheers,

Joseph

 

From: main@beta.groups.io [mailto:main@beta.groups.io] On Behalf Of J_Catlady
Sent: Tuesday, August 29, 2017 10:01 AM
To: main@beta.groups.io
Subject: Re: [beta] Guidelines tab

 

What do you mean by "a new email address"? I'm thinking of an "action" from the member page to "resend group guidelines"

 

J

 

On Tue, Aug 29, 2017 at 9:55 AM, Joseph Lee <joseph.lee22590@...> wrote:

Hi,

I second the below suggestion, possibly with a new email address that sends a copy of the guidelines page to members.

Cheers,

Joseph

 

From: main@beta.groups.io [mailto:main@beta.groups.io] On Behalf Of J_Catlady
Sent: Tuesday, August 29, 2017 9:53 AM
To: main@beta.groups.io
Subject: Re: [beta] Guidelines tab

 

p.s. Another helpful thing would be the ability to easily resend the the guidelines message to any member at any time - they might request them, they might need a reminder, etc. This would be for members who don't access the group via the web.
--
J

 

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu

 


--
J

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu

17481 - 17500 of 31948