Hello all,
The logs for the May 17th class "An Imperfect Introduction to Static Typing" are up and available at:
https://archwomen.org/media/project_classroom/classlogs/2015-05-17-an_imper…
-t
---- On Thu, 14 May 2015 11:06:01 -0700 tigrmesh wrote ----
>Hi,
>
>I'm copying an email sent to the arch-general mailing list earlier today:
>
>*******************
>
>Hello,
>
>The class "An Imperfect Introduction to Static Typing" is rescheduled to Sunday, May 17th at 23:00 UTC. HalosGhost is in the middle of moving and will not have internet at home at the original time. We apologize for the inconvenience and hope you will still be able to attend. Thank you for understanding.
>
>Original announcement:
>> Hello,
>>
>> HalosGhost will teach a class, "An Imperfect Introduction to Static Typing", on Thursday, 14 May 2015 at 21:30 UTC. It will tentatively be held in #archlinux-classroom. The class is expected to take about 1.5 hours.
>>
>> Static typing is where the type of data a variable will hold is defined when the program is written, and that definition is enforced during the program's run. In this class learn the basics to start reasoning about functions written in statically typed languages and understand the differences between static typing and dynamic typing. The class is for beginners to static typing. There are no prerequisites.
>>
>> HalosGhost, resident panda of the Arch Linux community, is well liked for eir* ability to dodge lazors. Ey enjoys programming and is familiar with many languages, like C, Java, Python, and Rust. Ey also knows a little Haskell.
>>
>> fsckd
>>
>> * Mercurian pronouns "ey" and "eir", https://theos.kyriasis.com/~kyrias/journal/10-mercurian-pronouns.html
>
Hi,
I'm copying an email sent to the arch-general mailing list earlier today:
*******************
Hello,
The class "An Imperfect Introduction to Static Typing" is rescheduled to Sunday, May 17th at 23:00 UTC. HalosGhost is in the middle of moving and will not have internet at home at the original time. We apologize for the inconvenience and hope you will still be able to attend. Thank you for understanding.
Original announcement:
> Hello,
>
> HalosGhost will teach a class, "An Imperfect Introduction to Static Typing", on Thursday, 14 May 2015 at 21:30 UTC. It will tentatively be held in #archlinux-classroom. The class is expected to take about 1.5 hours.
>
> Static typing is where the type of data a variable will hold is defined when the program is written, and that definition is enforced during the program's run. In this class learn the basics to start reasoning about functions written in statically typed languages and understand the differences between static typing and dynamic typing. The class is for beginners to static typing. There are no prerequisites.
>
> HalosGhost, resident panda of the Arch Linux community, is well liked for eir* ability to dodge lazors. Ey enjoys programming and is familiar with many languages, like C, Java, Python, and Rust. Ey also knows a little Haskell.
>
> fsckd
>
> * Mercurian pronouns "ey" and "eir", https://theos.kyriasis.com/~kyrias/journal/10-mercurian-pronouns.html
Hi,
Tags are used to organize to-do pages on the wiki. The current tags[1] are
a little confusing. I would like to rename two of them.
todo -> open
"todo" identifies open tasks. It would be clearer to just call it "open".
todo_issue -> todo
"todo_issue" identifies to-do pages. If "todo" gets renamed, this should
be renamed to "todo".
Also, I want to add a new tag:
important
This tag will identify tasks which are deemed important. What it says on
the tin. :-)
What do you folks think?
fsckd
[1] https://archwomen.org/wiki/todo:start
Hi all,
Here are some thoughts about mentorship, mostly taken from the discussion at the March, 2015 Arch Women meeting. There was to have been a small group meeting on IRC in March, but it was difficult to coordinate a time when everyone could be there. So it's happening here on the mailing list instead.
* Notes/ideas for the Arch Linux Women Mentorship Discussion *
People who expressed an interest in participating: meskarune, you, me, jy2wong, and alad. CalimeroTeknik, nisstyre, AndreeeCZ and yuvadm have put themselves on the list as willing to be mentors. They may want to come. And anyone else who wants to come.
Group will discuss and bring this to regular Arch Linux Women meeting in June. fsckd drafted some criteria/suggestions for the group to consider. Those are below.
The mentorship list now: https://archwomen.org/wiki/projects:mentorship:offers
Also,
Mentors, mentees, manatees http://im.skdat.com/data/gallery/21/manatee.jpg
=== General - clarify what we really mean by mentorship
Topics - Scope:
* what should be the scope of the topics allowed?
* Should they be limited to those usable for Arch?
Formality:
* How formal do we want this (program?) to be?
Commitment:
* what is the amount of time / level of commitment expected/required?
* For both mentors and mentees?
Topics - Ideas:
* IDEA: There are quite a few facets to arch, from bugtracking to packaging and documentation, so that's a good topic for mentorship
* IDEA: Allan indicated he might be willing to mentor someone about the toolchain. Needs more info
Process:
* How would this work in general?
* How do potential mentors communicate their areas of expertise?
* How do potential mentees communicate their area of interest?
* How do we connect the two?
* fsckd's thoughts and suggestions below
=== Privacy
"While I'm happy to mentor, I'm not sure I'm happy having my name up on a...err, shit magnet page. I really have no desire to have internet poo flung at me by random strangers who decide the arch women mentorship program is lulzy."
Privacy - General
General ideas/suggestions/considerations and blocks
- The list on the wiki now has the problem of zero privacy for mentors. The internet can be a scary place.
* How do we protect the privacy of mentors and mentees while keeping the process easy to use and accessible?
* Consider the specific attacks we're trying to defend against, and find possible solutions.
Privacy - Technical
Technical suggestions and ideas.
* Using the Arch Women Wiki - make use of dokuwiki's ACLs to create a special mentor group that can see the list of mentors
* People not in that group would be able to see the topics but not the names of the mentors. (names would be anonymized)
* Using the Arch Women Wiki - some other docuwiki feature
* Use something completely different
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~ fsckd's criteria/suggestions from the March General Arch Women meeting. I put them here because they are a good beginning for discussion.
General
- fsckd's suggestion on the general process:
* The process of connecting mentors with mentees should not be convoluted or tedious.
Privacy
- fsckd's suggestions on privacy:
* Mentors should retain their privacy. The list of mentors should be neither public nor anonymously accessible.
* Mentees should retain their privacy. There is no public list of mentees.
* People should easily be able to add themselves to the list of mentors, remove themselves from the list of mentors, and temporarily take a break from the mentorship program.
* Accessible to people not familiar with IRC.
* Skills should be publicly viewable even though list of mentors is not.
* <alad> so in short, a "private" mentor list, where people can easily add themselves to, and that can be queried by topic?
Hi,
I couldn't attend the May meeting due to irregular college hours, but
I've read the logs and saw the possible license of classrooms was
discussed. I'm attaching a mail from Kynikos confirming how projects
collaborating with ArchWiki should indeed keep the same license (as the
GNU Documentation License 1.3 describes).
The GDL isn't flawless, but it's well established and I think the
required logging of changes and attribution of content speak for itself.
"Invariant sections" can be added on-demand, but are by no means
mandatory. [1]
I also believe Kynikos makes a fair point on how both wiki and classroom
projects could share efforts (and he did show his enthusiasm towards
Classroom in a later email). Particularly in cases when time is too
short to prepare a full class, and to reach more people interested in
Arch Linux topics.
Regards,
Alad
[1]
http://en.wikipedia.org/wiki/GNU_Free_Documentation_License#Conditions
-------- Oorspronkelijke bericht --------
Onderwerp: Re: ArchWiki: GNU Documentation License
Datum: 2015-05-04 12:16
Afzender: Dario Giovannetti <dariogiova(a)gmail.com>
Ontvanger: Alad Wenter <alad(a)archlinux.info>
On 04/05/15 17:31, Alad Wenter wrote:
> Hi Dario,
>
> In the last ArchWomen meeting [1] the license choice for Arch Classroom
> [2] was discussed. The GNU Documentation License is an obvious
> possibility, as this is the license that ArchWiki uses.
>
> A question that arised is why precisily ArchWiki uses this license.
> ArchWiki:General disclaimer [3] links to the license, but otherwise all
> I've found is an explanation in the german ArchWiki [4]. Could you
> clarify on the matter?
>
> Regards,
>
> Alad
>
> [1] https://archwomen.org/media/meeting-logs/2015-05-03LOG.txt
> [2] https://wiki.archlinux.org/index.php/Arch_classroom
> [3] https://wiki.archlinux.org/index.php/ArchWiki:General_disclaimer
> [4]
> https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=…
Um... I'll start saying I've always hated all this legal stuff :P When I
joined the ArchWiki, it was already under the GFDL, and according to the
small research that I published in [1], it has always been since its
creation, in fact creating [2] has been the absolutely first edit of
all.
I don't know "why" that license was chosen over others, but relicensing
everything doesn't sound anything feasible to me, so if Arch Classroom
has to be hosted in the wiki, it has to bear the same license full stop.
In theory a fully compatible license could be used too, but the license
statement in the footer of the articles would stay as GFDL, so this
doesn't seem a viable option either.
Besides, if the Arch Classroom is hosted in the wiki, it's part of it as
a subproject, and cannot be considered as a separate project, so it must
abide to all the wiki regulations, in addition to the license. I'm
referring in particular to duplication of content, which is something
that the classroom articles generated copiously in the past and that the
wiki staff had to fix, still with some remainders, e.g. [3]. If some
wiki articles are not clear, effort should be spent in improving them,
not in creating "better" alternative articles.
Coming back to the license, it's not very clear to me what's your degree
of involvement with the Classroom project, but are you aware of a
particular reason why the use of GFDL is questioned? If not, we could
all just keep it simple and use our energies to contribute content to
the wiki as we've always done, regardless of the license ;)
[1] https://wiki.archlinux.org/index.php/ArchWiki:About#History
[2] https://wiki.archlinux.org/index.php/ArchWiki:General_disclaimer
[3] https://wiki.archlinux.org/index.php/Pacman_-_An_Introduction
Dario
Hello,
In past meetings people have emphasized the importance of having
pages for newcomers, outside observers and potential sponsors.
We also need to keep internal notes for people working on the
projects. Keeping these notes on the same pages intended for
newcomers would only confuse newcomers and would clutter the
notes intended for project participants.
I propose a project start page should give an overview. It is
for people not familiar with the project to learn what it is
about and how to participate. Internal administrative notes
should be on a separate admin page.
:start - describe the project, history, how it helps further
aw's goals, how to participate
:admin - administrative page, to-do list, notes on procedures
and common periodic tasks
classroom:start would be moved to classroom:admin.
mentorship:start and internships:start would stay where they are.
mentorship:admin and internships:admin would be created new.
How does that sound?
fsckd
Projects:
https://archwomen.org/wiki/projects:classroom:starthttps://archwomen.org/wiki/projects:mentorship:starthttps://archwomen.org/wiki/projects:internships:start
