I'n not familiar with list managers today, but in old Unix systems it used to be possible to put a ".forward" file in one's home directory that would automatically forward mail to another address.
Conceptually, an alias or symbolic link, so that more than one address ultimately pointed to one account. If a similar mechanism could alias the "perl6" prefix to "raku", that would seem a simple solution. On 3/15/21, William Michels via perl6-users <perl6-us...@perl.org> wrote: > Hello Richard (and all), > > The simplest solution seems to be reviving the historical > mailing-lists pertaining to the Perl6 effort, in particular, the > "perl6-announce" mailing list at perl6-annou...@perl.org . Daniel > Sockwell wrote as much in his recent email. New subscribers can sign > up at perl6-announce-subscr...@perl.org . > > According to https://raku.org/archive/lists/ , "perl6-announce [is a] > Moderated list for news of new lists, working groups, and so on. > Summaries from the top-level working groups are also posted here." > Presumably that includes reports from the Raku Steering Council. > > Yes, it can/should be renamed "raku-announce", but in the meantime why > not use it? > > Best Regards, Bill. > > W. Michels, Ph.D. > > > > On Mon, Mar 15, 2021 at 4:19 AM Richard Hainsworth > <rnhainswo...@gmail.com> wrote: >> >> Thanks to everyone that responded. >> >> It seems to me that the establishment of a common communication channel >> by the RSC (Raku Steering Council) would in itself define the Raku >> Community. Those who want to be a part of the community would track >> (follow, read, contribute etc) the channel. I don't think it is >> something that needs to be over-thought. Every channel has its >> advantages and disadvantages, and there's going to be someone who does >> not like the result. >> >> But the current situation of multiple channels of communicating is >> obviously going to create confusion. It would be like having multiple >> places for defining the same set of constants for a software project, or >> some other analogy of duplicating code that should be kept in one place >> and referred to, not written and maintained in multiple places. >> >> Also, if like-minded people have a way to share and cooperate, a >> community will build. Facilitating the growth of a community will have >> an impact on the acceptance of Raku as a language. >> >> Having multiple differing approaches to the same problem can be good - >> not arguing with that. But if there's no common way to share information >> about the multiple approaches, how can the different approaches be >> compared? If they can't be compared, then the advantages of multiple >> approaches are lost. And no one can be certain that their efforts are >> being considered. >> >> It turns out - from comments of JJ and Vadim - that Altai-man's >> initiative is a personal one. Had it not been late at night (for me) and >> had there been an established channel where plans for community >> resources are shared, I would have realised that straight-away. Instead, >> I got annoyed and lost sleep (silly and unreasonable, but I am human). >> >> Daniel, I look forward to hearing from you. Altai-man, please send me a >> link that I can catch up with what you are planning (I'm not so good at >> tracking multiple github repos). >> >> One of the things I would like to do is to set up a way of doing >> documentation that will allow for multiple languages to be possible, >> which means that it should be possible to show the same documentation >> file side-by-side in two languages, with text for each language kept in >> a separate file, but for equivalent places in the documentation to be >> synchronised. It would also be good to have revisionning history >> visible, so that updates in the main text can be tracked so as to update >> in a target language text. >> >> Regards, >> >> Richard >> >> On 14/03/2021 21:16, Daniel Sockwell wrote: >> > I agree with the points Vadim and JJ made: There's a good chance that >> > having a more official >> > communication channel would _not_ have prevented surprise here, since >> > the amount of progress >> > on the a potential docs redesign seems to have taken many people >> > (including me!) by surprise. >> > I guess that's what happens when our community has "forgiveness >> >> > permission" as a core value! >> > >> > That said, I also agree with Vadim that we should have a better way to >> > communicate things like >> > this, >> > even if it wouldn't have been relevant in this particular case. In fact, >> > we theoretically do: our >> > website lists the perl6-announce list, which is supposed to be "low >> > traffic (a few emails a >> > month)". >> > https://raku.org/community >> > >> > Looking at the archive for that list, it has been **very** low traffic >> > indeed: the last message was >> > >> > sent in 2015. So we clearly haven't been using it, and starting now >> > (when we're about to finally >> > move on to raku-* mailing lists) probably doesn't make much sense. But, >> > once we do, making an >> > effort >> > to actually use the raku-announce list seems like a good way to address >> > this issue. >> > >> > Finally, Richard, in the interest of not taking you by surprise again on >> > the same topic, I wanted to >> > mention that, inspired by the proposed doc site redesign and your >> > comments about the broader topic, >> > I'm now working on a proof of concept along the same lines (because I >> > have a slightly different vision >> > of what a redesigned website might look like, but don't think I can >> > communicate it without a POC). I >> > hope to be able to share more details in the coming days. >> > >> > Best, >> > Daniel / codesections >
