TB 78 Coming soon. The knowledge base needs you

Eric Moore emoore at fastmail.fm
Wed Jul 15 05:16:23 UTC 2020


>From: Matt Harris <unicorn.consulting at gmail.com>
>To: tb-planning <tb-planning at mozilla.org>
>Subject: TB 78 Coming soon. The knowledge base needs you.

>I understand folks are trying to resurrect the mozillazine
>knowledge base.? Perhaps they might invest some effort in the official
>documentation instead of creating a competing site to draw on the
>limited maintenance resources.

Its just me at the moment. I am not interested in maintaining KB 
articles on SUMO since I disagree with some of the unwritten policies:

1) Always follow the Mozilla party line (rather than being honest and 
state Firefox did something because it was in their best interest that 
unfortunately made life difficult for Thunderbird users, and here is how 
to make the best of the bad situation).

2) Don't provide consolidated background information such as whats 
available in http://kb.mozillazine.org/Mail_and_news_settings and 
http://kb.mozillazine.org/Files_and_folders_in_the_profile_-_Thunderbird .

The only reason I'm creating a different wiki is I'm trying to deal with 
a bad situation. Our site admin stated last Sept. that he didn't have 
time to make some of the changes our host requested so he was going to 
shut the site down, locked the wiki, and disappeared. I can't update the 
wiki and it badly needs updating, so I'm creating a new one and porting 
the most heavily used articles to it. The forums are still active and we 
found a potential replacement admin that we think the current admin 
would approve of, but he's still unreachable. We have no idea why he's 
acting this way.

I wish you didn't portray this as a zero sum game. MozillaZine is 
targeting a different audience. While there will always be some 
duplication I've linked to SUMO KB articles numerous times instead of 
creating a new one. I have no desire to port/update every existing 
MozillaZine KB article for Thunderbird. A lot of the duplication in the 
old wiki is because you ported our articles.

>I think it is also time for the community to discuss and decide what
>they want from the knowledge base.? Clearly the continuing efforts to
>resurrect mozillazine would indicate it's current form does not suit
>everyone.

I would like to see Thunderbird include a real troubleshooting wizard 
that can diagnose and fix common problems, and can also verify the 
health of a profile. I'm not talking about a better version of help -> 
troubleshooting information or a button similar to the "refresh Firefox" 
button. I'm talking about something more like the troubleshooting 
wizards in Windows.

If we had that it would need to link to some SUMO KB articles. They 
would have to be maintained in a timely manner. That's a big problem. 
For example its been over 2 years and there is not only no sign of any 
information about FIDO U2F support or what security keys work with it 
but all threads about it in the SUMO forum have been archived (which 
means a search within SUMO can't find them).

That is probably a terrible example but where is the mechanism to see 
that raw technical information is provided in a location that a 
potential author can use it? The developer didn't want to add that 
information to the bug report. My impression is that is pretty typical.

If that information was available somewhere I would have bought several 
U2F keys and written a KB article about WebAuthn/U2F for MozillaZine 
that somebody could have ported to SUMO if they thought there was 
sufficient demand for it. I was really interested in using that feature, 
but didn't want to spend any money without a developer at least saying 
that they had gotten it to work with a Gmail account. All the developer 
said was it passed a U2F conformance test. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1444101

I don't mean to single out a specific person, its a process problem. One 
of the reasons why I chose that example is because I suspect its been 
long forgotten about. There might be some bug report about the need for 
a TB SUMO article on U2F, but Bugzilla is so hard to use effectively I 
couldn't find one.

There is a sizeable number of problems that are tough to troubleshoot 
because there is no provision for logging startup errors. If that was 
implemented that would require a couple more KB articles.

I don't think it makes sense to write KB articles about add-ons on 
Thunderbird.net in general (beyond Lightning and Enigmail) but I think 
FiltaQuilla might be a special case. Don't document its features (let 
the authors support site do that), instead find some of the most common 
questions about how do I do .. that required using FiltaQuilla and 
provide some examples. I'm assuming when ImportExportTools NG gets 
merged into Thunderbird core its features will be documented in a KB 
article.

Too many of the SUMO articles seem to describe features rather than tell 
a user how to solve a specific problem. For example, effectively setting 
fonts/font sizes throughout all of Thunderbird. I can't find a SUMO KB 
article that talks about setting font sizes for the folder listing and 
folder pane, mention why you might want to use "Fonts for: Other Writing 
Systems rather than just Latin or suggest setting 
layout.css.devPixelsPerPx to 1.5. That information is hidden in threads.

A reluctance to document userChrome.css , userContent.css or using the 
config editor in a KB article doesn't help. I understand the issue 
(where do you draw the line on how much gets documented) but isn't the 
whole point of KB articles to have canned answers for common questions?

> There has always been a mozilla poilcy not to write a manual,? given 
we struggle to maintain some > knowledge base articles I am not in 
favour of a manual at this time.

Why does the "manual" have to be written by SUMO? Too many people seem 
to be hung up on something being official.

The tutorial at 
http://write.flossmanuals.net/thunderbird/about-thunderbird/ was written 
in 2010 and based on Thunderbird 3.1. It was a collaborative effort and 
pretty useful until it got too outdated. Perhaps Ryan could organize a 
similar effort?

Supposedly we're looking into making money from enterprise support. If 
we want to get into that in a big way would it be worthwhile to hire a 
contractor to write a manual that also dealt with many enterprise and 
admin specific issues?






More information about the tb-planning mailing list