For a while now, Clients has had a kind of free-for-all approach to suppporting individual clients. In the Working in Clients entry that gave information on the category, the approach was stated as "whatever is reasonable", and that's kind of been the official stance for a while: support clients to the extent that it's reasonable.
There are two problems with this policy. The first, of course, is just that it's hard to define. It's a lovely policy in theory, but in practice, it's hard to say what's reasonable and what's not. Hard to say what's approvable and what's not.
The second, and probably more important, problem is that it's not entirely fair. It's not fair to the users -- does someone who uses a client that is more obscure, but still official, deserve less support than someone who uses, say, Semagic? And yet, questions about Semagic features are more likely to get direct answers than questions about obscure-client features. And even with requests about a popular client like Semagic, there are times when someone's around to answer a feature question, and so it gets answered, and times when they aren't, and so it sits for a week and gets a "We can't help you, go ask in the comm" answer, even if the two requests are asking about the same or similar features. And it's not fair to the volunteers -- if there's a request that has two equally approvable answers, a "go ask in the comm" and a direct response to the question, the second one will generally be approved, which means that people who don't have or can't use a paritcular client are at a disadvantage.
So, I'm changing the policy from providing "reasonable" assistance to providing no client-specific assistance. The clients category exists to help with the connection between the client and LiveJournal; it does not exist to help with the connection between the user and the client.
Questions about how to download a client should be answered as they have been, with a pointer to the FAQ and without recommending a specific client. Questions about deleting a client should be answered as they have been. Questions about how to write a client should be answered as they have been, although these tend to be rare.
Bug reports should be answered in full, if (and only if) the problem is on LiveJournal's end. If the problem is with the client, send them to the client's community/developer. (If they mention the client they're using, which they usually do, and if it's one of the official clients, give a direct link to that community. If they don't mention the client, they can be told that the official clients' communities are linked from the download page; for other clients, including non-LiveJournal ones, they're on their own for finding the developer.) For known issues, it is encouraged -- but in general not necessary -- that you look in the client's community to see if there's already information about the issue (especially if there's a stated fix), and that you provide a link to that information/fix if it exists.
Feature requests should be told to look in the documentation / help files, and that additional questions should be directed to the client's community/developer. (Again, give them the link if it's an official client.)
If there are questions on this policy, or clarifications needed, let me know.
#
Reminder the first: Requests dealing with the Visions client must have information, in the answer, about how the client is no longer under development and they should switch to a different, more up-to-date client. This is extra-critical for requests where the primary cause of the problem is the visions client (such as the bit where it jumbles custom friends groups). For other client-specific requests, it is permissible (maybe even preferable) to skip the "talk to the developer" bit and just say, this client is no longer maintained or supported, go download and use a different one.
Reminder the second: Requests dealing with proxy/gateway clients (including, but not limited to, WAP clients) must have a disclaimer as described here. We've been fairly lax about this lately, but this policy is still in effect.
As you all probably know by now, one of the things that we're doing this week is leveraging our core competencies working on streamlining the process for support.
One of the things I want to do is to refine and clarify policy. This is primarily a Clients-specific thing; the admins as a whole are poking at the policies that are generic to support, but for this post I'm concentrating on Clients stuff.
Another thing I want to do is to get good documentation going. Partly in terms of FAQ (user-oriented) stuff, but also in terms of volunteer-oriented training materials.
I know what I want to clarify/add in terms of policy and documentation/training materials. What I want from you all, now, is to know what you want. Not everything that is brought up here will be used, but I want as much input as possible. From volunteers at any level, not just supporthelps, which is why this post is public. (Comment screening is deliberately enabled, for this round. Give me ideas, give me input, no matter how off-the-wall or weird you think it might be. I may not address everything that's raised, but I will consider all comments that are made. There will be a second post, later, for discussion of various issues.)
So. Tell me what you want. What policies are unclear, or contradictory? What policies do you think should exist? What policies do you have problems with? What training materials would you find useful? What already-existing training materials would you like clarification or expansion on?
Just an FYI for volunteers working in clients -- I won't be around much for the next three weeks while the semester winds down and I write exams. If you need something clients-y, please feel free to email me, or ask another supporthelp in clients. :)
Clients is a specialist category of LiveJournal support which deals with questions relating to the downloading, installation, and usage of LiveJournal clients.
What kinds of questions do you answer in Clients?
There are many different kinds of questions we get asked. Here's a list of some of them.
What's a client and where do I get one?
I don't want my client anymore, how do I remove it from my system?
My client won't connect to LiveJournal, why?
I'd like to create a new client -- how do I get started?
I have a new client I'd like listed on the download page, who do I talk to about that?
The music detection isn't working properly in my client, how do I fix it?
I want to remove a username from my client's login screen -- how do I do that?
I got [error] when trying to install/uninstall/use my client. What's that mean?
Are there any questions that don't belong in Clients, even though they look like they do?
Yep, there are a number of things that might look like Clients requests at first, but are not. For example:
I get 'Client error: Missing required argument(s)' when trying to update my LJ from the web. Why? -- Things dealing with the web interface are not Clients questions, even if they contain the word 'Client' in the error message.
I can't use the phone post/email post feature, why? -- Questions relating to these features are not handled in Clients. Only downloadable Clients, as listed on the download page or in lj_clients are handled in Clients.
I want to delete my LJ/delete all my entries/make all my entries friends only -- Questions of this type are not Clients requests, even though the answer may contain a mention of the usage of a client to perform the task.
I want to use my client for DeadJournal/GreatestJournal/anotherJournalsite, how do I do that? -- We don't provide support for other journaling sites, even if they do use LJ's software. So while the request will get *answered* in clients, don't treat it the same as requests asking about LiveJournal's functionality with clients -- tell them to go bug support at the site they're wondering about.
Do we recommend any one client over another? Do we offer more support for one client over another?
No. Clients official policy is that we treat all clients equally, meaning that we tell users to read documentation, the information provided by /download/, check posts in lj_clients, and ask questions of developers (if necessary) to find the right client for their needs.
It is acceptable, but not required, to recommend specific clients to a user if they are looking for a very specific feature. For example, a user who has expressed a lack of satisfaction with the journal download function and would like to try a client that has that capability. As only a very small number of clients are available that have such a feature, it is acceptable to mention them to the user.
Related, it is my opinion as Clients admin that no one OS will be supported more or better than another. This means that even though Windows users are the majority of LiveJournal users, they should not expect to receive more detailed information than users of other operating systems will be provided with. Support requests now have diagnostic information included, which means we do not need to guess which operating system a user might have (unless the user submitted their request via email, of course). This also means that volunteers who are not Windows users should not feel they cannot participate in the category. Please see the Clients Privilege Policy document for more details.
How much support are we supposed to provide?
My opinion on this is 'whatever is reasonable'. I realize this is a not a clear statement, so I will attempt to expand upon that.
If a user has a question about a specific function of a client, and someone who uses or has used the client is around to answer it, they are free to give a reasonable amount of information to the user. For instance, they can tell the user which menu the option they're looking for is in, and what option to choose.
If a user has a question about how to delete a client from their system, we should provide only the minimum information available. This means we tell the user there is an uninstaller with most clients (for Windows and MacOS, anyhow) and if that doesn't work to use the 'remove program' option that comes with their OS and to see its documentation for details. Step-by-step how-tos are not required, although if you wish to tell a user the specifics, that is fine. However, do note that we are LiveJournal support and not Windows/MacOS/*nix/etc support. If the user is reporting an unusual OS-based error when attempting to remove the client, they will need to contact their local systems administrator, or OS customer support for help.
If the user is asking questions about developing a client, we can point them to the userinfo of lj_clients or directly to the Client/Server Protocol page. We aren't expected to know the fine details of the development process.
If the user is asking a complex question (or what we often call in support a 'Bastard Freakie') it is acceptable to send the user to the client's developer for help. However, we need to have at least investigated the issue first. Often, an issue is known to the client's developer and a post has been made about it to the client's community, within comments to a post in the community, or at the client's website. We need to research the request first before sending the user directly to the developer.
On that note, I fully encourage developers of clients to participate in answering questions concerning their client on the support board. They will be required to heed support protocol concerning politeness in answers and internal comments, but there will be some leniency with support style or giving more information than is usually required. This is because the developer is the true authority on the functioning and usage of their client.
How useful are the entries in support_clients that give information on specific clients?
Some of the posts are up-to-date, but some are not. Essentially, use the posts as a starting-point for learning about issues/features of a client, but don't forget to check the posts from the client's community or information from it's website.
Over the next few months I will work to update the posts to bring them more up-to-date.
I have a question you didn't cover. How do I contact the admin?
isabeau is now clients admin; please contact her via her @lj email address or support@ with questions.
Preface: This document will explain the privilege policy for the Clients Support Category, including expectations and requirements. It is important to note before reading that the following represents the 'best-case' scenario and is not intended to be a 'laundry list' of requirements. Rather, it is a basic guideline for those working in the category.
Clients Category: Where do privileges fit in?
As discussed in the support guide, privileges are granted on a case-by-case basis in order to allow volunteers to better work in support. It is important to note that privileges are exactly that. They are not rights and will only be granted to those who show both consistent working ability in Clients and have an appropriate degree of professionalism in their dealings with others in a support capacity (including official communities, on the board, and in support-related emails). Also, because clients is a specialist category and requires specialist knowledge, we do not grant privileges based solely on work done in other categories.
Per-Level Expectations
All volunteers are expected to watch learn_support and lj_support. Participation in discussions is encouraged but not required.
Interim level privileges are granted to users working in the category as a means to further their ability to learn and improve their answers. All interims are expected to watch support_interim in addition to the communities listed above.
In order to gain I1 in Clients, volunteers are expected to demonstrate the following:
What clients are and where they can be downloaded
General understanding of Support writing style
Interest in working in the category (for example, asking questions on IRC or being pro-active and requesting a review)
In order to gain I2 in Clients, volunteers are expected to demonstrate the following:
General understanding of which issues are Clients issues and which are not, as per this post.
Understanding of the more common known issues in clients at the time of the review.
Knowledge of the Clients-specific howto tutorials and when they should be applied.
Supporthelps are expected to also watch support_clients, in addition to the communities listed above. In order to gain supporthelp in Clients, volunteers are expected demonstrate the following:
Understanding of when an issue is outside the scope of LiveJournal support.
Very basic understanding of the Client development process.
Ability to approve the answers of others in a fair manner (shown via priv-playing or testing)
Showing reasonable judgement of his or her own abilities when working the board -- knowing when it is ok to self-approve and when it is best not to work on a request at all (shown via reviews, priv-playing, or testing).
Per-Client Specialization
It is common that a volunteer may be interested in working in clients but has specialist knowledge of only one or two types of clients. For example, users who have good knowledge of the WAP clients available but do not generally use other clients, or users who have only used the Windows clients and have no knowledge of those available on other platforms. Volunteers who fall under this category may be granted privileges for working in Clients, based on their ability to answer questions on only a small sub-set of the clients available. We encourage users who are such specialists to answer requests dealing with their client(s) of choice and are appreciative of their help.
However, in order to gain supporthelp in Clients, volunteers who are per-client specialists must demonstrate the ability to answer general, non-platform specific questions about clients. For example, such questions as where clients can be downloaded or where information on client development can be found are examples of 'general requests' in Clients. Do note that this requirement is in addition to the supporthelp requirements as listed above.
How Skills are Assessed
Clients assesses skills by a combination of reviews, testing, and priv-playing. Reviews are required in order to gain all three levels of privileges. A test is also required to advance to the supporthelp level, and priv-playing will also be required in most cases, depending on the availability of requests at that particular time.
Requests for reviews can be emailed to the Clients admin, isabeau, via her LiveJournal email address. Please include 5-10 links to requests and any specific questions you might have concerning working in Clients.
Special Cases
While the Clients category does not offer privileges to anyone who is not actively working in Clients, the category does recognise members of LiveJournal's abuse team are granted courtesy I2 privileges for every public support category.
Losing Privileges
Inactivity demotions are done every quarter -- January, April, July, and October. Volunteers who are not actively working in the category and have not given notice to the admin should expect to lose their privileges by one step per quarter. This means a supporthelp will be demoted to I2, an I2 will be demoted to I1, and an I1 will have all Clients privileges removed.
Activity in Clients is assessed in many different ways. For non-supporthelps, board work is essential. For supporthelps, doing reviews, grading tests, and participating in policy discussion are all factored in when activity is assessed for demotion reasons, although there is an expectation that some board-work will be done during the previous quarter.
The Clients category currently offers courtesy I2 privs to all supporthelps in other categories. Starting this year, all privileges will be given on merit only. Courtesy I2 privs will no longer be given to supporthelps.
Volunteers who currently have courtesy I2 privs will be dropped to either I1 or no privs, depending on certain factors such as whether they earned I1 in the past and whether they were active in Clients last quarter. Volunteers who are interested in earning back their privs are always welcome to send me links for a review at my @livejournal.com address.
If anyone has any queries about this policy, please feel free to email me directly about them.
I've noticed that there are a few people who didn't notice this when it came up in the Misc Changelog Summaries posted to lj_support, so I thought it might be a good idea to point out to everyone that client logging has been turned off. This means that clients logged from before May 20 will show up in userinfos, but nothing afterwards. In particular, be careful when telling people to upgrade because you think they're using an older version of a client -- unless they've explicitly said so themselves, there's no guarantee they're still using that version.
The other big thing happening is that support is being implemented to allow posting to LiveJournal from Blogger clients. evanposted in lj_support earlier about that, and about the types of requests we'll likely get. I'm going to add that to the support_clients memories as a useful reference. Also, those of you who are members of lj_test might be interested in playing with various Blogger clients on the test server as described here.
After a good long while since the last downloads page update, I've prepared a heavily-modified version which solves the ordering problem that we were running into (a category for each new client). However, as a former support addict, I know how frustrating sudden changes to the system can be, so I wanted to run the changes past you all before submitting the patch for testing. I can make changes if problems arise with this model, but I'm hoping that it will make things simpler.
The new version divides all reasonably-active and useful clients into seven categories, five of which are new (X Window System, Handhelds, Command-line, Application-level, Miscellaneous). They appear in the order listed below. Please let me know if this will create any major problems, or if you have any suggestions as to the ordering of the clients. At this point the patch is still theoretical (although it has been coded), so things might change later.
Update: Please give your input. I know this might affect the ordering of the clients as support deals with them. If nothing comes up, I'll post the patch in a few days.
The Clients category was created in August 2002 to consolidate all clients support into a single category, rather than having separate categories for individual, popular clients, as it was before. This was done so that users of all available clients could receive support for their clients regardless of whether their chosen client had enough users to warrant a separate category.
Therefore, the Clients category of LiveJournal Support now provides support for all clients listed on the download page, although the developer may request that support is referred to them.
Things that belong in clients: - downloading a client - deleting a client - removing a client from StartUp - not being able to log into the client due to proxy/firewall/LJ being down - music-detection not working - enquiries into creating a new client - how to get a client listed on the download page
Specific to Visions/Semagic: - removing usernames from the login screen - client disappearing after minimising on start - clearing the mood-list for different journal sites
Things that sometimes belong in clients: - how to download a user's journal: these requests can only be moved to Clients if the user has expressed unhappiness at the layout of export.bml and would like alternatives
Things that don't belong in clients: - deleting LiveJournal accounts - anything that deals with clients in the context of LiveJournal's userbase
isabeau:
busy
silly