Subject: mailing-list for TeXmacs Users
List archive
From : Massimiliano Gubinelli <address@hidden>- To: Giovanni Piredda <address@hidden>
- Cc: TeXmacs <address@hidden>
- Subject: Re: Blog
- Date: Wed, 11 Nov 2020 15:35:43 +0100
Dear Giovanni,
> On 11. Nov 2020, at 14:32, Giovanni Piredda <address@hidden> wrote:
>
> Your arguments are fair. Let us work on the blog and let us see it develop.
>
yes, let's see how we can make it work.
> A section on misconceptions could also be ok.
>
> I would also like to hear your opinion on putting an accent on
> user-developed extensions (including making it easier for other users to
> find them by providing a collection of articles which link to repositories,
> and encouraging authors to submit them). It seems to me that the
> extensibility of TeXmacs should be used more; moreover, it automatically
> sets a distance ("plugin", "extension") between the core software and the
> extensions, so that hosting an article about an extension does not mean
> endorsing the extension, which remains under the responsibility of its
> author.
>
I'm eager to see extensions developed by users. The appropriate way to host
them seems to have external git repositories and to have in the blog an
article about the usage of the extension or about its developement, etc...
> For example it would be very nice if someone would write an extension for
> chemistry, or to give more ways to input colors (what I have found so far
> is named colors and html codes: are there any others?). These quite complex
> things could happen more easily if there is a "base" of simpler extensions
> written by users.
>
These are good ideas. However I would avoid starting with a list of possible
extensions, I think what we need in this initial phase is "quality material",
not proposals.
Personally I will try to write some articles on the internals of TeXmacs or
similar topics.
Max
> G.
>
> On 11.11.20 14:12, Massimiliano Gubinelli wrote:
>> Giovanni,
>> well, developers here means me (:)). Again, I'm open to discussion but
>> personally I do not think that a wiki in the style of wikipedia will work
>> (it is questionable also if it works for wikipedia). In the scientific
>> community the accepted way of communicating is via "curated" journals
>> after peer-review, and it also seems appropriate to me here.
>>
>> There should be someone (the editors) who put her/his "face" in
>> guaranteeing that the material is interesting and useful. That is the only
>> reason somebody would like to spend time reading it.
>>
>> If you have ever read places like stack-exchange you would realise that
>> sometimes the users suggest to other users wrong methods to solve problems
>> and if there is no more knowledgeable people around then these errors
>> sticks and are propagated around.
>>
>> Also the "editors" help the contributors to focus their material and make
>> it accessible. TeXmacs is still a small project and I do not think there
>> will be problems in filtering the contributions. I see the development of
>> the blog as the development of a piece of code, you do not want to develop
>> code in a "wiki" style.
>>
>> What happens to me often is that a new user want feature X implemented,
>> because it exists in software Y, Z or W, without taking time to appreciate
>> the internal logic of TeXmacs or the design tradeoffs and motivations.
>> Sometimes users think that something can be done in some way, but they do
>> not see that there is an easier way.
>>
>> Moderation help to remove common misconception. It would also be useful to
>> have a page on that: "Common misconceptions of newly arrived users" :)
>>
>>
>> But again, I think the forum and the mailing list are the right place for
>> discussions. The blog is for mature content which should not be difficult
>> to moderate efficiently and favour contributions as much as possible.
>>
>> Max
>>
>>
>>
>>> On 11. Nov 2020, at 13:56, Giovanni Piredda <address@hidden> wrote:
>>>
>>> If a curated blog is the one developers see most fit, then I am going to
>>> support it even if my initial preference was for a wiki mostly controlled
>>> by the users.
>>>
>>> Still I think that support for exchange of packages and style files among
>>> users would be good (strong benefits could come from this). The blog can
>>> do it by publishing articles where users describe their own extensions,
>>> with a link to a repository, and organizing these articles into
>>> collections.
>>>
>>> G.
>>>
>>>
>>> Am 11.11.2020 um 09:38 schrieb Massimiliano Gubinelli:
>>>> Dear all,
>>>>
>>>> I've added some guidelines for proposing content for the blog
>>>> (https://texmacs.github.io/notes/index.html).
>>>>
>>>> You can find them
>>>> here:https://texmacs.github.io/notes/editorial-guidelines.html
>>>>
>>>> I tend to think that the correct contribution system is a "curated" one
>>>> for many reasons:
>>>>
>>>> 1) technical: the addition have to be post-processes by knowledgeable
>>>> people to ensure that the HTML translation is acceptable and nice.
>>>>
>>>> 2) editorial: we want this place to be useful and meaningful. To me the
>>>> right approach is to consider it a "publication" where there is somebody
>>>> (an editor board) which cares about homogeneity and quality. So a bit of
>>>> centralization. This agrees with the fact that TeXmacs itself (i.e.
>>>> Joris :)) is very opinionated on design choices and aim.
>>>>
>>>> 3) decentralization: the fact that is a git repository means that it
>>>> still remains de-centralized to a large extent: if you want you can
>>>> clone the repository and publish the material in **any way** you like.
>>>> Like software this material will be open source, for all to use as they
>>>> see fit.
>>>>
>>>>
>>>> I feel that the editorial policy do not restrict your freedom as content
>>>> contributor: if you have a github account is very easy to publish your
>>>> own better version as "github pages".
>>>>
>>>> Anyway I'm open to discuss it, my intention is that it is
>>>> useful/informative/correct/pleasant to read, this should be the primary
>>>> goal.
>>>>
>>>> Max
>>>>
>>>>
- Blog, Massimiliano Gubinelli, 11/11/2020
Archive powered by MHonArc 2.6.19.