Messaging Service for Paratext

Question

(Milt_Jones , TSC, writes)

With all the major changes that are going to happen with registration, servers, all or nothing installs and other fun items, I am finding an acute need for a way to communicate with users. I feel that we need to be able to tell a user certain things when s/he starts Paratext. (Email is not an effective way to communicate with teams in Nigeria and it is difficult to call everyone on the phone.)

E.g. “Paratext must be upgraded in order for you to work on project XYZ. There will be 2 opportunities to upgrade: 1) Dec 13-15 at the Boboli Center for Bible Translation in TingaLinga, and 2) Jan 5-7 at the Luke Workshop - Lutheran Bible Translation offices of OogaBooga. If you do not upgrade at one of these times, you may not be able to open your project.”

E.g. “Your version of Paratext no longer works with project XYZ. Please contact the project administrator (XXX YYY) to schedule an upgrade.”

Without the ability to communicate these kind of urgent, administrative messages, upgrading Paratext will be very difficult.
If we could make a PUD available for project administrator and consultant for this kind of notification in 7.5, we will be able to reduce the confusion on a couple hundred Seed Company projects.

I presume this would involve something like

1. Adding Tools > Send Team Message which would allow typing a simple (unformatted?) text message.

2. Adding Tools > View Team Messages. It would show all the team messages in chronological order (most recent first). Previously unviewed messages would have a distinct color.

3. Whenever the user does a send/recv if there are any messages new messages we would automatically open View Team Messages.

I presume it would take a day or two to do this. Prioritization committee members please answer the following three poll questions (other may submit comments as replies)

Should we implement this in 7.5 and 7.6?

• Yes
• No

0 voters

Show results

Should sending a message be restricted to only project administrators or consultants?

• Yes
• No

0 voters

Show results

Do we need to allow an organization level administrator to send such a message to a group of projects? This would take an additional day or two.

• Yes
• No

0 voters

Show results

舊文章 - 以原文顯示

Answer 1

I would strongly recommend sticking to unformatted text (i.e. no bold, italics, font changes, etc.). Formatting text is very complicated and could take several days to a week more of work to do. Especially if we are putting this into 7.5, I don’t think we want to make it overly complicated.

舊文章 - 以原文顯示

Comments

I have no problem with unformatted text, especially if this will speed the implementation.

舊文章 - 以原文顯示

Answer 2

Should we implement this in 7.5 and 7.6?

· Yes
Should sending a message be restricted to only project administrators or
consultants?

· Yes. I can see my teams confusing the Notes and Message system
and sending me Note content inside Messages.

· Do we need to allow an organization level administrator to send
such a message to a group of projects? This would take an additional day or
two.

· Yes – Not only for upgrade notifications which would include
entity specific details, this would be a great place for workshop and
Scripture funding notifications, etc., since email addresses are always
changing.

舊文章 - 以原文顯示

Comments

Shegnada – I’m not sure if your votes have tallied - you need to vote on the website. I’m confused by our yes vote on item 2. It would seem that your comment says you don’t want them to send messages.

anon848905

舊文章 - 以原文顯示

---

Thanks, anon848905, I needed that instruction. But my answer to 2) was Yes, it should be restricted from translators because they would use it for content that should be in NOTES instead. But john_nystrom’s idea of turning it on and off is better, with OFF being the default.

舊文章 - 以原文顯示

Answer 3

Re. #2, I wonder how much more work it would be to turn permission for this on/off the same way we turn on/off permissions for other things, e.g. Biblical Terms Renderings, spelling status, etc. I’d rather not restrict writing team messages to only administrators and consultants, but occasionally it might be necessary to turn it on/off for specific users. The scenario Shegnada mentioned is but one example of why this could be necessary.

To #3 I’m inclined to vote No, but I would like to hear comments from somebody who thinks it is necessary.

舊文章 - 以原文顯示

Answer 4

Re. #2, I would not want to restrict the ability to communicate. It feels like giving someone a cell phone to receive text messages but disabling the “send text” option. Each team will need to decide on communication. Some will centralize communication, others not.

The functionality (and possibly UI) seem to be similar to “mark point in project history”. A message text box will be disconnected from the text itself so it should become obvious very quickly that it is not the place for a project note.

舊文章 - 以原文顯示

Answer 5

As my original idea implies…

1. I think this should be implemented in 7.5, but if that is not possible, then as soon as possible, because we will face these kinds of upgrade (and other) issues every so often.
2. I can see the benefits of restricting who can message as well as the benefits of allowing broader messaging. I would be happy to see a phased approach where administrators are allowed in 7.5, and possibly a permissions based messaging later.
3. Organizational administrator is a nice idea. I would need to think that through in relation to the Seed Company, but this would simplify contacting every project Admin/Consultant to tell them to send out a message.

舊文章 - 以原文顯示

Answer 6

I don’t like being the lone dissenter, but I disagree that this functionality is necessary in Paratext. There are countless ways to send messages to members of a team. I am concerned that we would be using precious developer resources to develop and maintain functionality that already exists. Perhaps I am simply not understanding the situation for the original submitter. For instance, I don’t understand why email doesn’t work as a solution, but using a server-based messaging system would work.

Again, I apologize for being critical, but my background is as a software developer and every time that we reinvented the wheel in projects that I was involved in, it was a mistake.

舊文章 - 以原文顯示

Comments

Hi Mark,
I understand your concerns. In several place email is simply not a priority for the teams. And even when they try to use it, it often fails because of the networks (mostly cell networks) or because of the very poor providers and routine address changes. Texting is probably the most useful way to communicate, but we have no way to track team members phone numbers and those phones often get loaned to others, etc.
Since we know that the team members use PT and Send/Receive - even if it is sporadic due to the networks - there is a simple logic to alerting a team member through the tool (PT) they are using to work with and, in the case of project notes, already communicate with.
The magnitude of the 8.0 changes are sufficient to already make me scramble as to find a way to roll this out. So far, I don’t have a lot of good options.
If it is simply a matter of finding resources, I can probably find or raise the funds for something this critical to a roll out.

舊文章 - 以原文顯示

Answer 7

Dear anon451647,

Should we implement this in 7.5 and 7.6?

• Yes - even though in practical terms PT 7.6. would make more sense
  than 7.5. if we want people to upgrade their PT on a regular basis.

Should sending a message be restricted to only project administrators or
consultants?

• No - once we have it, why to restrict it?

Do we need to allow an organization level administrator to send such a
message to a group of projects? This would take an additional day or two.

• Yes - even though the real demand of it might appear only once in a
  while.

anon982572

舊文章 - 以原文顯示