FAQ / FAQ备注网站改造 [英] FAQ/FAQ notes site makeover
问题描述
有一些建议可以更改常见问题解答
网站的格式，以便于维护。 VK建议和XML程序。
Matt Kruse建议使用wiki。我觉得互动的东西会很好。 Jim Ley指出wiki文档并不总是运行良好。
我认为每个
页面上的用户评论的书籍类型层次结构将是这是一个很好的方式，因为它已经非常成功了。
PHP和MySQL。如果任务
不是太繁重，我愿意写一个Rails应用程序来执行此操作。我提出了一个简单的小演示（不是生产
准备好了）。
http://seriousjavascript.info
（试试插入代码示例）
我认为能够没有ftp维护站点会更好。
课程功能可以随着时间的推移添加，任何人都可以用svn查看
Rails应用程序并提交补丁。
我我并不是说我会成为JavaScript技术专家之一
或Jim Ley会停止托管该网站。
也许这取决于Jim Ley和Randy Webb做出决定，如果
格式会有变化。我只是认为我会提供
优惠并且球可能会开始滚动。
彼得
Peter Michaux在11/21/2006 11:28 PM说：以下内容：
你好，
有一些建议可以更改FAQ
网站的格式，以便于维护。 VK建议和XML程序。
这会遇到一个重大问题，即不懂XML的人会感到遗漏了b
。对我来说，请求修改的当前方式没有任何问题。它很简单，任何人都可以使用
发布给该组。
Matt Kruse建议使用wiki。
维基的问题有两个：
1）如果你授予开放访问权限（就像维基百科一样） ），然后你有
任何人发布任何东西和人们花太多时间纠正
的东西。
2）如果你限制访问一些人，你如何决定那些人将会是谁？无论谁在你的名单上，你都会有人抱怨它。如果他们现在抱怨并且要投诉那么，b
$ block $ class =post_quotes>
我认为互动会很好。
对我来说，当前的格式除了更新之外还没有问题。我有一半
同意理查德的意见，因为很少有人发布甚至片段以便在他们想要说的问题（草案提案）中说这应该是在
常见问题解答"然后让理查德把它写出去，以便人们可以继续抱怨它说的话。我从来没有写过笔记部分，
甚至是FAQ的条目，所以我不能声称完全无罪与
关于那个部分。
Jim Ley指出wiki文档并不总是运行良好。
是的，由于上述原因，并非一个人的JRS喜欢使用。
我认为在每个
页面上有一个用户评论的书籍类型层次结构将是一个很好的方式，因为它已经非常成功了两个
PHP和MySQL 。
虽然PHP / MySQL和Javascript常见问题解答之间的差异很大但是b $ b。一个在服务器上运行，您可以在其中指定环境，而另一个则不是.b $ b另一个没有。
书籍类型层次的问题虽然很难将
全部放在一页上。人们现在不读单页，
他们为什么有兴趣阅读整本书？特别是如果他们不得不追捕他们想要的东西。在常见问题解答上简单搜索
页面现在可以找到（或拒绝）您要查找的内容。什么会对常见问题解答感觉很好但是在页面本身中是一个搜索/查找/突出显示
所以你不必手动完成。
如果任务
不太繁重，我愿意写一个Rails应用程序来执行此操作。我提出了一个简单的小演示（不是制作
准备好了）。
http ：//seriousjavascript.info
（尝试插入代码示例）
插入代码示例isn对大多数人来说没有任何好处，而不是
确定它在FAQ中有什么好处。能够动态地将代码插入FAQ页面的能力是什么？
我认为能够维护网站没有ftp会更好。
课程功能可以随着时间的推移添加，任何人都可以用svn查看
Rails应用程序并提交补丁。
我我并不是说我会成为JavaScript技术专家之一
或Jim Ley会停止托管该网站。
也许这取决于Jim Ley和Randy Webb做出决定，如果
格式会有变化。我只是认为我会提出
的报价并且球可能会开始滚动。
我个人认为，最好的办法是给我一个星期或
两回到上一次更新并尝试首先更新常见问题解答
，然后根据需要转到其他格式。我确实认为
现在需要将锚点问题更改为单词锚点而不是
数字。我仍然需要与Jim取得联系才能获得一个
用户名/密码才能进入服务器，但已经开始寻找
的入门请求。
-
兰迪
机会有利于预备心灵
comp.lang.javascript常见问题 - http://jibbering.com/faq
Javascript最佳实践 - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb写道：
Peter Michaux在11/21/2006 11:28 PM说了以下内容：
Matt Kruse建议使用wiki。
维基的问题有两个：
1）如果您授予开放访问权限（就像维基百科一样） ），然后你有
任何人发布任何东西和人们花太多时间来纠正
的东西。
我同意类似维基的方法是最好的。我也认为它应该是开放式访问的
。当然，关于wiki社交动态和
信息完整性的争论很古老，并且在其他地方都有很好的记录，但是我为
一个人看到了尽管有破坏和不准确，
精心编写的具有恢复能力的wiki具有非凡的信息完整性和可靠性。事实上，社区创建的文档（例如wiki）将充分利用整个社区体验的广度.B
。 JavaScript作为
一种语言已经成熟到一个单独的，无助的，b $ b不能成为它的所有方面的专家。因此，让每个人都贡献他们所知道的
，并让管理员拒绝访问特定的
个人或冻结编辑内容有争议的网页。
即使在比
clj小得多的社区内也能很好地工作。
我觉得有些什么互动会很好。
对我来说，当前的格式除了更新之外还没有问题。我有一半
同意理查德的意见，因为很少有人发布甚至片段以便在他们想要说的问题（草案提案）中说这应该是在
常见问题解答"然后让理查德把它写出去，以便人们可以继续抱怨它说的话。我从来没有写过笔记部分，
甚至是FAQ的条目，所以我不能声称完全无罪与
有关。
这将使得Wiki格式无法实现。你不能抱怨
你也有自己编辑的钥匙。没有什么可以阻止你
只是把东西放在那里，如果结果不准确，
其他人可以再把它拿下来（希望在讨论中解释）
页面为什么删除或编辑帖子。
我认为书籍类型的文章层次结构每个
页面上的用户评论将是一个很好的方式，因为它已经非常成功地支持PHP和MySQL。
虽然PHP / MySQL和Javascript常见问题解答之间的差异很大，但是b $ b。一个在服务器上运行，您可以在其中指定环境，而另一个则不是.b $ b另一个没有。
书籍类型层次的问题虽然很难将
全部放在一页上。人们现在不读单页，
他们为什么有兴趣阅读整本书？特别是如果他们不得不追捕他们想要的东西。在常见问题解答上简单搜索
页面现在可以找到（或拒绝）您要查找的内容。什么会对常见问题解答感觉很好但是在页面本身中是一个搜索/查找/突出显示
所以你不必手动完成。
我个人不喜欢PHP文档。我认为首先学习Python是我的偏见
及其超级有用，简洁的解释
所有内容，但我也觉得PHP的文档是有点臃肿，
有太多的旧信息和巨大的用户评论帖我不想要
来阅读。我只是希望目前就最佳实践达成共识。
维基提供的内容。
只是我的2c。
-David
Randy Webb写道：
维基的问题是两个 - 折扣：
1）如果您授予开放访问权限（就像维基百科一样），那么您有任何人发布任何内容和人们花费太多时间来纠正
的东西。
我不认为这里有人会想做那么多纠正。
维基百科已经存在，如果有人知道clj
资源在某种程度上得到了验证它具有不同的吸引力。
2）如果限制访问少数人，你如何决定那些人将会是谁？无论谁在你的名单上，你都会有人抱怨它。如果他们现在正在抱怨并且当时抱怨b $ b，那么这个好处是什么？
我认为这不是一个大问题。所有开源项目
都有一部分具有提交状态的贡献者。你可能会尖叫为
提交状态，直到你脸色发青，但是如果那些交给你的人提交状态不会给你，那么你运气不好。重要的
部分有不同的方式，这样每个人都可以贡献和感受
部分努力。
我认为每个
页面上带有用户评论的书籍类型层次结构将是一个很好的方式，因为它已经成功了两个
PHP和MySQL。
虽然PHP / MySQL和Javascript常见问题解答之间的差异很大，但是b $ b。一个在服务器上运行，您可以在其中指定环境，而另一个则不是.b
。
是否无法在JavaScript FAQ
服务器上指定环境？ Jim Ley提到他会通过SSH访问已知的
人。
书籍类型的问题层次结构"虽然很难将
全部放在一页上。
完全没有。实际上这很容易。沿着书树向下走
并连续各节。
人们不读单页现在，
然后整个练习都是徒劳的。
实际上我认为这是一个重点。为什么他们不读它
吧？人们一直在搜索JavaScript信息。
也许新格式更令人兴奋，并且更多地使用了常见问题解答和常见问题解答。
br>
为什么他们有兴趣阅读整本书？
我的意思是faq页面和笔记的书籍式组织。不是
必须1000页的笔记。
特别是如果
他们必须去寻找什么他们正在寻找。在常见问题解答上简单搜索
页面现在可以找到（或拒绝）您要查找的内容。
如果FAQ本身是层次结构中的单个节点，那么这将保留
。或者FAQ部分可以动态连接到
生成完整的常见问题解答。有选项。
虽然在页面中是搜索/查找/突出显示，但是对于常见问题解答会有什么好处？本身
所以你不必手动完成。
这将是一个不错的功能。
如果任务
不太繁重，我愿意写一个Rails应用程序来执行此操作。我提出了一个简单的小演示（不是制作
准备好了）。
http ：//seriousjavascript.info
（尝试插入代码示例）
插入代码示例isn对大多数人来说没有任何好处，而不是
确定它在FAQ中有什么好处。能够将代码动态插入FAQ页面的能力是什么？
我认为这个插入代码示例在笔记中会很好。在
插入代码之后，可以很容易地使用Firefox
Firebug控制台或其他javascript控制台中的代码。我最近一直用自己的笔记来使用这个
技巧，这非常有用。它有时很好地与代码进行交互。
很高兴。 JavaScript是一种独特的
编程语言，它以HTML格式呈现的示例可以像这样动态
动态。
我认为能够在没有ftp的情况下维护网站会更好。
课程功能可以随着时间的推移添加，任何人都可以用svn查看
Rails应用程序并提交补丁。
我我并不是说我会成为JavaScript技术专家之一
或Jim Ley会停止托管该网站。
也许这取决于Jim Ley和Randy Webb做出决定，如果
格式会有变化。我只是认为我会提出
的报价并且球可能会开始滚动。
就个人而言，我认为现在最好的办法是给我一个星期或
两回到上一次更新并尝试首先更新常见问题解答
，然后根据需要转到其他格式。
我在想如果需要改变格式，那么两个
的努力（内容和格式）可以并行进行。 br />
彼得
Hi,
There have been a few suggestions for changing the format of the FAQ
site to make it easier to maintain. VK suggested and XML procedure.
Matt Kruse suggested a wiki. I think something interactive would be
good. Jim Ley pointed out wiki documentation doesn''t always work well.
I think a book type hierarchy of articles with user comments on each
page would be a great way to go as it has been so successful for both
PHP and MySQL. I am willing to write a Rails app to do this if the task
is not too onerous. I put up a simple little demo (not production
ready).
http://seriousjavascript.info
(Try the insert code example)
I think being able to maintain the site without ftp would be nicer. Of
course features could be added over time and anyone could checkout the
Rails app with svn and submit patches.
I am not suggesting I would be one of the JavaScript technical experts
or that Jim Ley would stop hosting the site.
Perhaps it is up to Jim Ley and Randy Webb to make the decision if
there will be a change in the format. I just thought that I''d make the
offer and that the ball might start rolling.
Peter
Peter Michaux said the following on 11/21/2006 11:28 PM:Hi,
There have been a few suggestions for changing the format of the FAQ
site to make it easier to maintain. VK suggested and XML procedure.That suffers a major problem whereby people who don''t know XML will feel
left out. To me, there is nothing wrong with the current way of
requesting a modification. It is simple, and available to anyone that
can post to the group.
Matt Kruse suggested a wiki.The problem with a wiki is two-fold:
1) If you grant open access (much like wikipedia does), then you have
anybody posting anything and people spending too much time correcting
things.
2) If you limit access to a few people, how do you decide who those
people are going to be? No matter who is on that list you are going to
have people complaining about it. If they are complaining now and going
to complain then, whats the benefit?
I think something interactive would be good.The current format, to me, is fine other than getting it updated. I half
agree with Richard in that not many people post even snippets to get put
into the FAQ (Draft Proposals) they just want to say "This should be in
the FAQ" and leave it up to Richard to write it out so that people can
still complain about what it says. I have never written a Notes section,
or even an Entry for the FAQ so I can''t claim total innocence with
regards to that part.
Jim Ley pointed out wiki documentation doesn''t always work well.Yes, and for the above reasons, not the one''s JRS likes to use though.
I think a book type hierarchy of articles with user comments on each
page would be a great way to go as it has been so successful for both
PHP and MySQL.The difference between PHP/MySQL and Javascript FAQ''s are substantial
though. One runs on the server where you can dictate the environment and
the other doesn''t.
The problem with a "book type heirarchy" though makes it difficult to
put it all in one page. People don''t read the single page there is now,
why would they be interested in reading an entire book? Especially if
they have to hunt what they are looking for. A simple Search on the FAQ
page now will find (or reject) whatever you are looking for. What would
be nice for the FAQ though is a Search/Find/Highlight in the page itself
so you don''t have to do it manually.
I am willing to write a Rails app to do this if the task
is not too onerous. I put up a simple little demo (not production
ready).
http://seriousjavascript.info
(Try the insert code example)The insert code example isn''t any good to most people though and not
sure what benefit it would have in a FAQ. What''s the point of being able
to dynamically insert code into a FAQ page?
I think being able to maintain the site without ftp would be nicer. Of
course features could be added over time and anyone could checkout the
Rails app with svn and submit patches.
I am not suggesting I would be one of the JavaScript technical experts
or that Jim Ley would stop hosting the site.
Perhaps it is up to Jim Ley and Randy Webb to make the decision if
there will be a change in the format. I just thought that I''d make the
offer and that the ball might start rolling.Personally, I think for now, the best thing to do is give me a week or
two to go back to the last update and try to get the FAQ now updated
first, then move on to a different format if it is desired. I do think
the anchor issue now needs to be changed to a word anchor instead of
numbers. I still have to get in touch with Jim to get a
username/password to get on the server but have already started hunting
down entry requests.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb wrote:Peter Michaux said the following on 11/21/2006 11:28 PM:Matt Kruse suggested a wiki.
The problem with a wiki is two-fold:
1) If you grant open access (much like wikipedia does), then you have
anybody posting anything and people spending too much time correcting
things.I agree that a wiki-like approach is best. I also think it should be
open-access. Of course, the debates on wiki social dynamics and
information integrity are old and well documented elsewhere, but I for
one have seen that in spite of vandalism and inaccuracies, a
well-written wiki with revert ability has a remarkable amount of
information integrity and reliability. The fact of the matter is that
a community-created document such as a wiki will take advantage much
more of the breadth of an entire community''s experience. JavaScript as
a language has matured to the point where a single individual, unaided,
cannot an expert on all aspects of it. So let everyone contribute what
they know, and have an administrator who can deny access to specific
individuals or freeze editing on pages where content is contentious.
This works remarkably well even within communities much smaller than
clj.
I think something interactive would be good.
The current format, to me, is fine other than getting it updated. I half
agree with Richard in that not many people post even snippets to get put
into the FAQ (Draft Proposals) they just want to say "This should be in
the FAQ" and leave it up to Richard to write it out so that people can
still complain about what it says. I have never written a Notes section,
or even an Entry for the FAQ so I can''t claim total innocence with
regards to that part.This would be rendered moot with a Wiki format. You can''t complain if
you also have the keys to make edits yourself. Nothing''s stopping you
from just putting stuff up there, and if it turns out to be inaccurate,
others can take it down again (hopefully explaining on a discussion
page why the post was removed or edited).
I think a book type hierarchy of articles with user comments on each
page would be a great way to go as it has been so successful for both
PHP and MySQL.
The difference between PHP/MySQL and Javascript FAQ''s are substantial
though. One runs on the server where you can dictate the environment and
the other doesn''t.
The problem with a "book type heirarchy" though makes it difficult to
put it all in one page. People don''t read the single page there is now,
why would they be interested in reading an entire book? Especially if
they have to hunt what they are looking for. A simple Search on the FAQ
page now will find (or reject) whatever you are looking for. What would
be nice for the FAQ though is a Search/Find/Highlight in the page itself
so you don''t have to do it manually.
I personally don''t like the PHP documentation. I suppose it''s my bias
from learning Python first and its super-helpful, concise explanation
for everything, but I also feel that PHP''s docs are kind of bloated,
with too much old info and a huge thread of user comments I don''t want
to read through. I just want the current consensus on best practices.
Which a wiki provides.
Just my 2c.
-David
Randy Webb wrote:
The problem with a wiki is two-fold:
1) If you grant open access (much like wikipedia does), then you have
anybody posting anything and people spending too much time correcting
things.I don''t think anyone here would want to do that much correcting.
Wikipedia already exists for this and if folks know that the c.l.j.
resource is somewhat verified it has a different appeal.
2) If you limit access to a few people, how do you decide who those
people are going to be? No matter who is on that list you are going to
have people complaining about it. If they are complaining now and going
to complain then, whats the benefit?I don''t think this is really a big problem. All open source projects
have a subset of contributors with commit status. You could scream for
commit status until you are blue in the face but if the people who hand
out commit status won''t give it then you are out of luck. The important
part is having different ways so that everyone can contribute and feel
part of the effort.
I think a book type hierarchy of articles with user comments on each
page would be a great way to go as it has been so successful for both
PHP and MySQL.
The difference between PHP/MySQL and Javascript FAQ''s are substantial
though. One runs on the server where you can dictate the environment and
the other doesn''t.Is it not possible to dictate the environment on the JavaScript FAQ
server? Jim Ley mentioned he would pass out SSH access to a known
person.
The problem with a "book type heirarchy" though makes it difficult to
put it all in one page.Not at all. That is quite easy actually. Just travel down the book tree
and concat the sections.
People don''t read the single page there is now,Then the whole exercise is futile :)
Actually I think this is an important point. Why don''t they read it
now? People are searching for JavaScript information all the time.
Perhaps a new format would be more exciting and generate more use of
the FAQ and FAQ notes.
why would they be interested in reading an entire book?I meant a book-type organization to the faq page and notes. Not
necessarily 1000 pages of notes.
Especially if
they have to hunt what they are looking for. A simple Search on the FAQ
page now will find (or reject) whatever you are looking for.If the FAQ itself is a single node in the hierarchy then this would
remain. Or the FAQ sections could be concatenated on the fly to
generate a complete FAQ. There are options.
What would
be nice for the FAQ though is a Search/Find/Highlight in the page itself
so you don''t have to do it manually.That would be a nice feature.
I am willing to write a Rails app to do this if the task
is not too onerous. I put up a simple little demo (not production
ready).
http://seriousjavascript.info
(Try the insert code example)
The insert code example isn''t any good to most people though and not
sure what benefit it would have in a FAQ. What''s the point of being able
to dynamically insert code into a FAQ page?I think this insert code example would be good in the notes. After
inserting the code then it is easy to play with the code in the Firefox
Firebug console or another javascript console. I have been using this
trick with my own notes quite a bit lately and it is very useful. It is
nice to interact with the code live sometimes. JavaScript is a uniqe
programming language in that it''s examples presented in HTML can be
dynamic like this.
I think being able to maintain the site without ftp would be nicer. Of
course features could be added over time and anyone could checkout the
Rails app with svn and submit patches.
I am not suggesting I would be one of the JavaScript technical experts
or that Jim Ley would stop hosting the site.
Perhaps it is up to Jim Ley and Randy Webb to make the decision if
there will be a change in the format. I just thought that I''d make the
offer and that the ball might start rolling.
Personally, I think for now, the best thing to do is give me a week or
two to go back to the last update and try to get the FAQ now updated
first, then move on to a different format if it is desired.I was thinking that if a change in format was desired then the two
efforts (content and format) could proceed in parallel.
Peter
这篇关于FAQ / FAQ备注网站改造的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
