Commit 095e0c12 authored by Andrew Lee's avatar Andrew Lee
Browse files

freenode is IRC

parent eed4d9ca
Pipeline #56 passed with stages
in 2 minutes and 19 seconds
- heading: About freenode
- name: The project
link: pages/project
- name: The people
link: pages/people
- name: The philosophy
link: pages/philosophy
- name: The policies
link: pages/policies
- name: 'freenode #live'
link: '//'
- name: ''
link: '//'
- name: Acknowledgements
link: pages/acknowledgements
......@@ -33,15 +25,11 @@
- name: '/'
- name: 'non-SSL: 6667'
link: 'irc://'
- name: Channel guidelines
link: pages/changuide
- name: Catalyst guidelines
link: pages/catalysts
- name: 'freenode #live'
link: '//'
- name: '#freenode-bbs'
link: '//'
- name: '#freenode-jobs'
link: '//'
- name: Knowledge base
link: 'kb/index/all'
- name: Supporting the project
link: pages/support
- name: Contributing
link: pages/contributing
- name: Group registration
link: pages/groupreg
title: 'Chat'
cats: [connect,general]
cats: [connect]
title: 'Knowledge Base'
cats: [connect,general,using]
cats: [connect,using]
title: 'Technical'
cats: []
Title: User and Project Cloaks
There are two types of cloak which can be set on accounts on freenode; both
replace the hostname/IP displayed when you are connected (but only when you're
identified to NickServ—see below).
There are also gateway cloaks, which are automatically applied if you're
connecting from certain providers, gateways or web IRC clients, whether or not
you are identified to NickServ, and which override unaffiliated cloaks.
Project cloaks
Project cloaks typically take the form `project/role/user`, for instance
`freenode/staff/bigpresh` (though some take other forms). They are designed to
demonstrate that the user is connected to a project in some way. Different
projects use cloaks for various roles—some only use them for their core
team, some will assign user cloaks as well.
Project cloaks can only be requested by a registered group contact of an
already [registered group](pages/groupreg)—they should contact a member of
freenode staff to request that a user be given a project cloak.
Unaffiliated cloaks
Unaffiliated cloaks for users take the form `unaffiliated/accountname`. They
indicate that you are not affiliated with any specific project on freenode.
They can also help obscure your IP from casual observers to a certain
degree—but see the weaknesses section below.
Bots can also be cloaked to indicate their owner—unaffiliated bot cloaks
take the form `unaffiliated/owneraccountname/bot/botaccountname`.
Gateway cloaks
If you are connected via a gateway which sets a gateway cloak (for instance,
some web-based chat interfaces or bouncer/shell providers) you will receive an
automatic gateway cloak—for instance `gateway/web/foo/ip.` — these
gateway cloaks override unaffiliated cloaks, but do not override project cloaks.
There are also gateway cloaks which may denote that the host the user is coming
from is recognised as a large-scale NAT gateway (where the public IP is being
shared by many individual customers behind it) or conferences, where many users
are at one location temporarily.
Cloaks do not effectively hide your IP
Cloaks can help obscure your IP address/hostname from casual observers, but
should *not* be relied upon for that purpose, as they are not reliable:
- Connecting before identifying to NickServ (or whilst services are
unavailable due to a netsplit or maintenance) will show your uncloaked
IP/hostname. [Authenticating with SASL](/kb/answer/sasl) avoids this if
configured to abort the connection on authentication failure.
- Connecting via a gateway (for instance, most web-based irc clients) will
override unaffiliated cloaks (see the "gateway cloaks" section above)
- Due to the nature of IRC services, there are some tricks which can cause
services to reveal a cloaked user's IP/hostname.
- Accepting a DCC chat/file transfer session, or clicking a link someone sends
you could reveal your IP to them
For these reasons, we advise you to consider cloaks as only very basic
protection from casual observers, and a way to stop your IP/hostname being
passively logged in most cases, but caution that they cannot be relied upon to
hide your IP/hostname robustly—if you want that, you should consider an [IRC
[VPN]( or [our Tor hidden
Do consider, however, just how much you need to hide your IP address; it's
disclosed routinely during normal Internet usage—for instance, every website
you visit will necessarily see your IP address, unless you are using a VPN or
Tor. Many, many users happily use IRC for decades, never hiding their IP
address, and do not have any problems.
To reiterate, the primary purpose of cloaks is to show your project
affiliation, or lack thereof. Hiding your IP is not their primary purpose, and
they cannot be fully relied upon to do that.
Also, even when you are cloaked, you will see your own IP if you /whois
Requesting a cloak
Once you've read and understood the above, if you would like an unaffiliated
cloak, please join the #freenode channel or speak to a member of the staff
team. Note that cloaks are a privilege, and staff have the right to deny that
privilege to users if they deem necessary.
For project cloaks, a registered GC for the project needs to contact staff to
request the cloak be added to the desired user.
Title: General Expectations for Conduct
In addition to the general [policies](pages/policies) governing behaviour when
using freenode, we strongly encourage all participants to adopt the [channel
guidelines](pages/changuide) and [philosophy](pages/philosophy) to help keep
the network a friendly and productive place.
In particular, we would urge all users to keep the following in mind:
- We expect all users to act in good faith at all times, and this includes
assuming the same of others. Where another user's behaviour admits several
interpretations, work on the basis of the most charitable one until you have
strong evidence to the contrary.
- freenode aims to be welcoming, inclusive, and non-discriminatory and we
encourage everyone to be tolerant and respectful of others.
Title: Channel Namespaces
Our [policies](pages/policies) outline that channels on freenode fall into one of two categories.
Channels that begin with only a single # character are primary channels. Channels that begin with
two # characters are topical or ‘about’ channels.
Primary Channels
Primary channels are reserved for _official_ channels of on-topic projects.
A registered group (as outlined on the page about [group registration](pages/groupreg)) can claim
ownership over primary channels bearing the group's names or name prefixes. For example, freenode
itself owns the channel ‘#freenode’ and all channels beginning with ‘#freenode-’.
Primary channels do not expire. If you represent an on-topic project and would like to take over a
primary channel for that project, do not hesitate to [contact us](pages/groupreg).
Topical Channels
Topical or ‘about’ channels are intended for _unofficial_ channels that are _about_ something that's
on-topic. For example, an unofficial channel to talk about freenode is ##freenode. Topical channels
do not mean ‘anything goes’. In particular, they are not for [off-topic use](pages/policies).
Topical channels are given out on a first-come, first-served basis. They will expire if unused for
a long time, see our [policies](pages/policies) for details regarding when this occurs. You can
contact us on IRC with a request to take over an expired topical channel.
Title: Channels
Channel Policies
In general, local policy and rules for each channel are set by that channel's operators. While we encourage all channel operators to adopt our [channel
guidelines](pages/changuide), if a project or community decides to operate otherwise then we respect their decisions. If you believe that the way in which a
particular channel is run contravenes our [ground rules](pages/policies) or runs counter to the freenode [philosophy](pages/philosophy) then you should raise
your concerns first with the channel owners, and then with freenode staff who will address cases on an individual basis.
Why can't I join a channel?
Title: Catalyst Guidelines
The "catalyst" role is critical to freenode and an essential building block of effective communities. No one is required to be a catalyst, but the users who perform this role ensure the smooth and efficient functioning of the network.
The IRC platform does not automatically produce a stable culture of cooperative effort. Even in cases where cooperation is intended, misunderstandings and personality incompatibilities can result in an extremely chaotic and hostile environment. Catalysts help prevent and resolve misunderstanding, calm the waters when users have difficulties dealing with each other and provide examples of constructive behaviour in environments where such behaviour might not otherwise be the norm.
Catalysts try to resolve problems, not through the use of authority and special privilege, but by fostering consensus, gently nudging participants in the direction of more appropriate behaviour and by generally reducing the level of confrontation rather than confronting users with problems.
Channel and network administrators may be catalysts and, indeed, are encouraged to take on that role. Channels which recognise the importance of the catalyst role will foster more effective coordination of effort. An important characteristic of successful catalysts is the infrequency with which they wear authority or invoke special privilege.
freenode volunteers and sponsors are advised that an understanding and appreciation of the catalyst’s role is essential to understanding the nature and intended purpose of the network.
### An effective catalyst is:
1. **Relaxed.** To keep things calm, you yourself must be calm. Learn the skills of staying genuinely relaxed. Know your limitations; when you can't handle a problem situation calmly, get calmer heads involved.
2. **Open-minded.** It is easy to make assumptions about other people's motivations. When you decide someone is behaving maliciously, you have made an assumption about their motivation which may be difficult to disprove. Try to make your assumptions about other people's motivations as positive as possible.
3. **Responsible.** Peer-directed projects are a group activity with a strong need for responsible individual behaviour. Rumours, innuendo and gossip can derail projects and ruin reputations. If everybody knows something is true, who is "everybody?" Did the person you are talking to get their information from documented, factual sources, or is it hearsay? If you cannot be sure of the answer to those questions, should you be passing on what they have said?
4. **Unobtrusive.** It is not necessary to invoke authority to help solve a problem, and far better if you do not. Look for an opportunity to nudge the situation into a more productive track. Do not criticise the user if a quiet change of subject, or a private conversation on a completely different topic, can help make the problem fade away.
5. **Realistic.** Accept the personalities of your users and concentrate on problem resolution. Do not expect people to suddenly change their personalities to make problem resolution easier.
6. **Careful.** Everything you say will be interpreted by the users with whom you interact. Consider how your remarks will be interpreted before you make them. Make sure the message you convey is the one you intend.
7. **Attentive.** Understand the situation you have walked into before you act. Question your assumptions. Look for signs that you may have misinterpreted the situation, in order to avoid causing difficulties for a user who did not create the problem.
8. **Minimalist.** Do not do more than you need to in order to resolve a problem. A problem scene is often the wrong time and place to set policy. Concentrate on the resolution, and on collecting information you can think about later.
9. **Courteous.** Even under time pressure, courtesy costs little and impresses people a lot. It is not about whether working with the person is easy or difficult; it is about setting the right tone.
10. **Cooperative.** Look for opportunities to get people involved in the resolution of their own and others' problems.
11. **Someone with an internal locus of control.** Catalysts concentrate on solving problems, not bestowing blame. Treat the situation as the problem, accept the users for who they are and try to figure out how best to help resolve the difficulty.
12. **A user.** Remember that you are not in charge. Everybody runs their own little corner of the world. Let them do the job they are capable of. Just help the process along as unobtrusively as possible. Other catalysts are users as well, and nobody is perfect.
We are all just here to do our best to keep things running well.
Title: Channel Guidelines
IRC is a low-bandwidth method of communication, in comparison with physical presence. Many of the cues of physical communication, tone of voice, facial expression, hand movements, etc., are missing in IRC, since only text is transmitted back and forth.
Speakers in physical proximity with each other communicate quite a bit of emotional context via this extra bandwidth. This context enables them to avoid misjudging the intent of their conversational partners. It also functions as an unconscious negative feedback mechanism to reduce the incidence of emotional "firestorms" which tend to disrupt the efficient flow of conversation. Human beings look for this feedback, and indeed they may have evolved to require it. In the low-bandwidth world of IRC, they must instead rely on emotional feedback from the text they receive.
This process is subject to exaggeration. Small amounts of emotion become magnified in the perception of the observer. So, it is very important to keep channels calm. An informal conceptual measurement of the emotional content of a channel is its "channel temperature."
Think of a person's emotional state as kinetic energy. Enthusiasm, happiness, anger, frustration all add to the energy level. The more emotion is experienced, the "hotter" the participant. The average emotional state of a channel is its temperature. Emotions in IRC become exaggerated and conveying them directly increases channel temperature. Pent-up frustration, in particular, is often released as a series of inappropriate, "high energy" outbursts. An important objective of the freenode channel guidelines is to avoid "feedback loops" in channel interactions by reducing channel temperature.
The guidelines which follow are designed with the benefit of years of experience with IRC, beginning during the 1993-1994 period when the design limitations of IRC began to become clear due to the increasing scale of IRC networks. Adopting the guidelines will help improve the overall quality of your channel, and of the discussions that can take place in it.
We intentionally avoid drawing a distinction between channel operators and users. Everyone is a user, regardless of their privilege level, and each user has the ability to influence the usability of the channel.
- **Polish your catalyst skills.** The catalyst role is crucial to keeping channel interactions friendly and efficient.
- **Look for the best in people.** If you assume people have no self-control, they will confirm your belief. If you look for personal responsibility, and ask for personal responsibility, most people will respond well.
- **Set a good example.** Be what you want other people to be. If you want them to be calm, be calm. If you want them to be courteous and friendly, be courteous and friendly. The habitual behaviour of people on a channel is the most powerful influence on newbies arriving on the channel.
- **Be nice if someone messages you.** They have gone to the trouble to seek out someone with the background to help them. You are it! Be flattered they have singled you out. If you think they will get better support by asking their question on channel, just let them know.
- **Don't display channel operator privileges.** Displaying these privileges on your nick with a "+o" attracts participants who are interested in gaining them and using them actively; it also attracts the attention of participants who react negatively to authority. Have your account added to the channel access list and op yourself only when needed.
- **Use channel operator privileges sparingly.** Each time you use them you raise the channel temperature. Users will be pleased with you, angry at you, frustrated that you used them inappropriately, envious that you have control over the discussion. None of these reactions may be conscious on the part of other users, but all of them increase the channel temperature.
- **Avoid highlighting and repetition.** Words and sentences in all-uppercase, heavy use of highlighting, beeping (^G) on public channels, repeating the same lines over and over--all of these behaviours irritate people and raise the channel temperature.
- **Avoid emotive speech.** Slang pertaining to sex and sexual orientation, excretion and religious oaths are rarely used to discuss the applicability of those topics to your group's activities. In general, language with strong emotional content and only light meaning should be considered "emotive speech". It does not matter whether the language is socially acceptable or unacceptable. For example, use of the word "fsck" which does not refer to a Unix filesystem check is emotive. Similarly, use of the word "gay" which has nothing to do with homosexuality is emotive. Emotive speech raises the channel temperature.
- **Avoid sensitive material.** Some users on freenode channels, particularly on public channels, are quite young. Others are parents or teachers who might have young children nearby. As you type comments or ASCII art, or post URLs for others to view, please consider the age range of other users on your channel, and respect the right of parents and teachers to decide when and if to expose the children in their charge to material or language which might offend, confuse or raise difficult issues.
Additionally, some of our users connect to freenode from corporate environments. Employers may be unhappy with the unexpected appearance of sensitive material on workplace computers. Please be considerate and avoid posting such material when you are not completely sure it is safe to do so.
- **Avoid advocacy debates.** BSD versus GPL, vi versus emacs, centralised versus decentralised, RMS versus ESR: these discussions are frequently religious and may not involve significant new ideas. They can also raise the channel temperature quite a bit. Certain advocacy discussions, such as those revolving around actual religion or politics, are almost guaranteed to raise the channel temperature to levels that make other conversation difficult.
You might not get too worked up if you are arguing the relative merits of poll() or kqueue(), but if you walk into a discussion with a strong emotional need to "get your way," consider the possibility you are simply arguing preference or personal affiliation. Advocacy discussions are best held quietly, via /msg, or on channels especially created for the purpose.
- **Take criticism to private message.** Criticising someone's behaviour on channel holds them up to public scrutiny in a negative way. It's usually overkill. In your messages, do not address the subject of whether you have channel operator privileges; just be courteous. Request nicely that they change their behaviour. In many cases you will discover that problem user you are dealing with is merely inexperienced. An aggressive tone makes for a longer and more involved discussion, and pent-up frustration which will raise the channel temperature sooner or later. You can always use channel operator privileges, or have someone else use them, as needed; but with a courteous tone, you will need to do that a lot less.
- **Don't be elitist.** Today's newbies are tomorrow's experts. A support channel is a place where people with knowledge lead by example. Is the example you want to set that technical knowledge is a hierarchy of control, or that people with knowledge have an inherent social advantage over people who do not? Helping other people takes patience. It is better not to answer a question than to use the opportunity to emphasise the limitations of the person you are trying to help.
- **Don't be caught by support burnout.** It is nearly impossible to answer every technical question that comes to your channel. In many cases, the problem does not lie in the technical aspects of the question; cultural barriers may get in the way of communication, or it may be difficult to explain to a newbie just where to begin. When you try to answer every question, regardless of difficulty, you set yourself up for **support burnout**.
Support burnout is nearly always accompanied by the feeling that you are losing control of your time, that the people you have set out to help are making unreasonable demands. The problem is that you are taking on too much responsibility; but it begins to appear instead that the problem is the end user who is asking for help.
Different people react to support burnout in different ways. Some offer malicious advice ("rm -rf /" etc.) to newbies. Some insist that every question a newbie asks should be answered with a URL or by lists of manual references.
When the staff of a support channel suffer from support burnout, they are likely to set arbitrary rules for participation; these might include prohibiting the use of certain phrases in channel, or disallowing the use of private messages to contact channel members. Staff might promulgate a lengthy, multi-page rules document ending with a special procedure the user must employ to be voiced in the channel (to make sure they have read the entire document before asking any questions).
Such arbitrary rule sets tend to grow longer over time, because they do not solve the real problem. **You cannot answer every question, and you should not try.** Be gentle, be courteous, be flexible and be as patient and helpful as you can---but let someone else try to answer questions that you find too frustrating. Do not try to be a superhuman support machine.
- **If you are considering publishing channel logs**, think it through. The freenode network is an interactive, real-time environment where discussions may be heavily influenced by external context. Even on public channels, most users do not weigh their comments with the idea that they will be enshrined in perpetuity to stand on their own. For that reason, few participants publish logs and we encourage those communities that do to make their participants aware of this fact.
title: Contributing
freenode relies on several interoperating pieces of software to provide
an open environment for peer-directed projects. In the spirit of
[our philosophy][philosophy], we use free and open source software to do so.
We collaborate with upstream development teams for the projects powering
the network to ensure the specific needs of our communities can be met
appropriately. In addition, there are various custom-developed tools
and modules that we make available.
The majority of our software is available on [our GitHub profile][github]
and contributions are always welcome. You can find an overview of open
tasks [on our projects board][roadmap]. We encourage you to contact us
in `#freenode-dev` if you want to contribute or have any questions.
## The platform
### IRCd
We're in the process of migrating to
[Solanum](, a joint
effort by freenode and OFTC to develop an IRCd tailored to the needs of
centrally-managed, community-oriented IRC networks. Solanum is a fork
of Charybdis, once freenode's upstream, but seeks to continue where it
left off and is managed as an independent project. Users are encouraged
to submit issues and patches directly.
### Services
To provide registration of accounts and channels as well as related
functionality, we run Atheme, an IRC services package. We maintain
[a fork]( from which to coordinate
development; you are welcome to submit patches either to upstream
Atheme, or to our fork if you'd rather leave upstreaming your changes
to us. There is also a collection of freenode-specific extension modules
we maintain directly.
### Website
Our website []( is built on the
idea that freenode is a community plattform that currently uses IRC.
We prioritise information about freenode, and the policies and philosophy
that guides us. The website is also home to important documentation on
the usage of the network. While we want to encourage users to ask questions
in the `#freenode` channel, some information is better kept in our knowledge
## The Development Team
When contributing to freenode you will get to interact closely with our
development team.
title: Group registration email
robots: noindex
You have probably landed on this page as part of registering a group on freenode.
Before you proceed to email us, please make sure you have done the following
* Read about [group registration](/groupreg)
* Had a look at [freenode's policies](/policies)
* Discussed your project with a member of the group management and community team, or any other member of freenode staff
After you have done so and have been referred to this page, include the following
details in an email to <>.
# About your project
Your project name:
Your project description:
freenode staff member you have discussed this registration with:
Links to places we can find out more about your project:
# About you and your staff
Your NickServ account (primary group contact):
Your relationship to the project:
NickServ accounts of alternate group contacts:
# About freenode
Channels you'd like to claim (typically #projectname):
Channel namespaces you'd like to claim (typically #projectname-*):
Cloak namespaces you'd like to claim (typically projectname/*):
Title: Group registration
This page describes group registration and the use of the freenode group
contact. Group registration allows your project or organisation to maintain
unambiguous contact with the freenode project volunteers and group registration
represents an official relationship with freenode.
### On-topic groups
Groups considered to be on-topic for freenode are primarily free and open-source
software projects, and other peer-directed projects, for instance Linux User
Groups (LUGs), student societies, and other collaborative efforts, or projects/companies
of general interest to our user base.
### Group registration:
**Represents an official relationship between freenode and your project or
> By registering your group, you are indicating that you are maintaining an
> official presence on the network. If your group is a legal entity, we want to
> make sure that management has approved your registration.
**Requires no special type or level of participation.**
> You may maintain as little or as much control over your channels as desired.
> You may cloak your members, employees or participants, or not, as you decide.
> You may apply to sponsor a server if that is something you wish to do.
**Is accomplished by discussing your registration with the community team.**
> If you think a group registration would benefit your project, let any member
> of staff know over IRC; they'll assess whether your group appears to be
> on-topic and advise you on what kind of information and authorisation you'll
> need.
### Two types of group contacts exist for freenode:
#### The primary contact.
This contact registers to establish that your group intends to create a
relationship with freenode. The primary contact should have the authority to
make the determination that your group intends to register, with the specifics
depending on the type of group:
1. Legal entities. A primary contact should belong to upper management or the
organisation's board. This authority can be delegated further in the case of
larger organisations, but it is not recommended; in cases where such delegation
occurs, contact with the organisation is often lost and the group registration
must subsequently be removed.
2. Informal, project-oriented groups. Informal groups vary considerably in
their internal organisation. If the group is run by a single project leader or
developer, that person should submit a group registration. If it is run by a
larger core group or by voting across the project, the voting group should make
a collective decision to register and should appoint one of their number as
primary contact.
#### The secondary contact.
Secondary (or alternate) contacts are appointed by the primary contact. A
secondary contact may be assigned limited access and/or privileges. They need
no special level of authority; delegate whatever level of authority seems
appropriate. We will not expect them to make policy decisions, just to find out
the answers to any questions that are raised.
### Group registration provides:
1. Additional channel management capabilities. Projects and organisations are
entitled to own channels bearing their names. Your group contact can request
changes in channel ownership in accordance with this policy and can directly
request changes to access lists and configuration for any channels you own.
2. Group hostname cloaks. Cloaks allow your project or organisation to grant
official recognition to project participants. Your group contact maintains this
cloak list.
3. Problem solving. When there is a problem with one of your channels or if
there is a complaint by a user or a question about policy, we will pass it on
to your group contact.
We aim for a reasonable degree of flexibility where we deal with groups. If you
mention any particular needs your project might have, we'll try to accommodate
#### Your group contacts:
**Are designated by your project or organisation.** For example, a group
contact might be your IT manager or someone involved with your project
**Can be one person or several.** You decide who acts as group contact. Each
contact can be designated to handle issues pertaining to your entire group, or
to a limited set of projects or users. You can designate primary and backup
contacts if you wish.
**Acts as your "goto".** When you need someone to talk to us about a network
issue, your group contact is the person. They are your formal point of contact
with our network staff.
**Acts as our "goto".** We will ask your group contact whenever we have any
question about your project or organisational policies as they pertain to
participation in the network.
## Group Registration and Channel Ownership
Channels on freenode are owned and operated by the groups which register them.
No minimum level of activity or moderation is expected or required of channel owners.
The network exists to further on-topic use, as explained in our [policies](
and channels or groups may be removed from freenode for activity which is considered
to be off-topic.
Groups using freenode are strongly encouraged to adopt the [channel guidelines](
Primary channels are reserved based on a formal or informal claim, external to IRC, to a specific project group, or
trademarked name. Topical or reference channels are reserved on a first-come, first-served basis by groups wishing to
discuss a project, group or topic.
### Free and Open Source Software (FOSS).
Project coordination, support, discussion or contact channels associated with software projects which are licensed under terms consistent with the [Debian Free Software Guidelines](, Free Software Foundation's [Free Software Definition]( or the Open Source Initiative's [Open Source Definition]( (preferably all three) are considered to be on-topic.
### Non-Software-Related Peer-Directed Project.
Channels which serve projects combining open, informal participation and broadly-licensed, widely-disseminated creative output are considered to be on-topic. If you believe your non-software project may meet the criteria for a non-software peer-directed project, please consult a staffer or email support at freenode dot net.
### Non-Governmental Organization (NGO).
Coordination, support, discussion or contact channels run by educational institutions, registered not-for-profit entities and other non-governmental organisations (NGOs) and their related consortia are considered to be on-topic. Be sure to register your group or organisation.
### Governmental Entity.
Coordination, support, discussion or contact channels run by local, national or international governmental entities are considered to be on-topic. Don't forget to register your group.
### News Media.
Formal news organizations with an interest in our target communities are encouraged to create contact channels on freenode.
### Corporate.
Contact channels for registered corporate or business entities or consortia with an interest in our target communities are considered to be on-topic.
### Standards.
Discussion channels associated with official standards committees or with informal standards groups are considered to be on-topic.
### Geographically-Based Interest Group.
Channels associated with formal or informal geographically-based interest groups are considered to be on-topic. These include local
Linux and FreeBSD user groups (LUGs and FUGs) and community wireless groups. If your group doesn't fall into one of those categories, but you think it might meet the criteria, please consult a staffer or email support at freenode dot net.
### Other groups.
Other groups not covered by the above examples may be suitable for the network. Please drop an e-mail to if you want to find out if your group/project is a good fit for freenode.
## freenode Group Advisory Board
In order for freenode to provide the best possible service to the communities
we serve, it is important for us to receive feedback from the projects with
which we have relationships.
We invite all current (and future) Group Contacts to join GAB, the freenode
Group Advisory Board. While we hope to see many Group Contacts involved with
GAB in an advisory capacity, GAB membership is of course optional.
freenode will consult the GAB on matters relating to services given to
groups/projects, any addition to, or change of, group specific policy and other
relevant issues.
If you are a current Group Contact and wish to get involved with GAB, please
contact staff on IRC or email groups at freenode dot net for instructions on
how to subscribe to the freenode-groups mailing list. If you're considering
becoming one, just let us know your email address when registering.
We'd love to hear how you feel we could improve the service for your community.
Thanks in advance for any help you can provide!
## Group Management & Community Team
The Group Management & Community Team comprises, among others, the freenode staff; together they will act as your
liaisons during the group registration process and throughout your tenure on the
freenode network. If you wish to discuss the group registration process, find out
if freenode could be a good fit for your project or register your project as
a group, please feel free to drop any of the team members a line on IRC.
If none are online, feel free to reach out to staff in general and they will
forward your request to the team, which will get back to you as soon as possible.
Once you have discussed your project with a staff member, you'll be asked to
email <> with the details of your request, including any
formal verification information that might be required. If you're a PGP user,
feel free to encrypt to:
445B 4A56 5E9D F351 DD80 CE98 FCF3 9BAB 6166 AFB8
Title: The Philosophy
There are several elements to the freenode philosophy. The project was originally founded to provide interactive discussion facilities to **peer-directed project communities**. Peer-directed projects combine open, informal participation with broad licensing and wide dissemination of output.
Our basic principles are:
- **Community members benefit from better access to each other.** Putting a number of projects in close proximity in an interactive environment creates linkages between developers and projects, and helps community members take better advantage of each other's work.
- **Communication and coordination skills are important to community projects.** Peer-directed projects work because the paradigm works. Developers and community members are not unusually gifted at project coordination and communication. But improving those skills can make projects work better.
- **Friendly interaction is more efficient than flaming.** Calm, relaxed discourse without angry contention provides for better exchange of information. Flaming produces situations in which the listener must contend with the state of his or her emotions at least as much as with the comprehension of a speaker's comments.
- **Project developers are self-driven.** No one guarantees your work will be used, but only you decide whether a project is worth doing. There is no single right approach to any design, implementation or support problem, and friendly competition is a fundamentally good thing.
- **Peer-directed project communities need to grow.** Many valuable peer-directed projects chronically lack skilled, motivated developers with time to devote to them. The potential base for peer-directed project communities includes anyone with the skills and interest to participate. These communities must continue to grow.
- **Licensing must be free.** For peer-directed projects to succeed, their creative output must be widely available and usable without significant restriction. For software projects, the [Debian Free Software Guidelines](, the Free Software Foundation's [Free Software Definition]( and the Open Source Initiative's [Open Source Definition]( provide guidelines to help ensure that project creative output remains free. For artistic projects and for the printed word, licenses provided by [Creative Commons]( and efforts such as the [GNU Free Documentation License]( and the [FreeBSD Documentation License]( help keep creative output free.
Licensing which preserves the ability of newcomers to contribute, and maintains a low barrier to entry for development, is essential to the health and success of peer-directed projects.
......@@ -2,148 +2,21 @@
Title: The Policies
Terms of Service
The freenode project exists to help all communities. Its focus is peer-directed projects
and open innovation communities. Peer-directed projects combine open, informal participation
with broad licensing and wide dissemination of output.
freenode provides facilities to peer-directed project communities and the combined efforts
of open innovations, including those of free and open source software (FOSS). Freenode
utilizes IRC to service its users &mdash; but the network was created to serve groups that
exist outside of IRC. freenode is designed to encourage community members to improve their
skills in the areas of cooperative effort, interpersonal communication and project
coordination, and to create a real-time bridge to the outside world for our target communities.
Nickname ownership
Nicknames are allocated on a first-come, first-served basis, to the first person
who registers the name with NickServ. However, we expect users to act in good
faith and reserve the right to remove a nickname registration where we believe
that this has not been the case.
Nickname and account registrations expire ten weeks after they are last used.
For nicknames, ‘used’ means that you were using the nickname while logged in to
the account which owns it. For accounts, ‘used’ means that you logged in to the
account, regardless of the nickname you used to do so. Nicknames which are the
primary account name expire only when the entire account is expired.
In some cases, such as for very old accounts, we may, at our discretion, extend
the expiry time of a nickname or account. We will not normally do this beyond 15
weeks past the last use.
Some nicknames and accounts, including but not limited to some of those owned by
current or former network staff, do not expire at all. These accounts can be