• TipsForInHouseUserGroups

In House User Groups

This page is intended to give the reader some hints and tips on "In House User Groups" within a company or organization.

What is an In House User Group

In House User Groups are similar to LocalUserGroups but with some specific differences that make starting, or running, one a little different. They are normally closed in the sense of being restricted in their membership to people within the specific company or organization. They often have some value above and beyond Local User Groups in that:

• They can promote the use of Python within the company or organization

• You will likely be able to discuss specific projects, issues & challenges within your organization with less worries about confidentiality Note that some confidentiality issues may still exist and be aware of them.

• Internal resources, training, etc. may be available that would not be available or relevant to people outside of the company or organization.

• The ability to network and locate possible internal assistance with projects or problems can be invaluable.

• They may be able to present internal projects to a wider internal audience, be it other user groups or the wider corporate structure.
• Involvement may well assist with professional development in some companies or organizations.

The aim of this page is to try to gather some tips and best practices for such groups but not everything will apply in all cases. Some points are more applicable to large, distributed or multinational, companies than to smaller, single site ones and, of course some are more general and apply to just about all cases so, the rest of this page is split into 3 sections: General Points, Small Organizations & Large Organizations.

General Points

A few general points to keep in mind:

• Sound out the level of interest in the possibility of having an In House User Group - make it clear that this is just a possibility at this stage.

• Seek and obtain official permission before you start - Issues to consider include:

  • Who do you need to get approval from?
  • How much interest has been expressed
  • Will you be using company resources such as computers, bandwidth, etc?
  • Will "meetings" take place in work hours?
  • How often will these "meetings" take place?

  • Will discussions be allowed to include current projects & problems and does that potentially impact confidentiality, IP, etc?

  • How many people are likely to be involved initially and over time?
  • Will the user group possibly be representing the company externally in some contexts, e.g. at wider conferences, in presenting papers, etc.

  • 'What are the expected benefits to the company' - this is an important point to prepare for your discussion - if there is clear benefit to the company or organization then approval is more likely to be granted. Some points to make are above in the "What Is" section.

• Have more than one organizer: this avoids conflicts with holidays, sickness, urgent projects, retirement, etc. and can avoid things going stale.

• Always have an organizer in the meeting at the advertised start time.

• Cancellations, rescheduling &/or relocation should be done as early as possible and be as widely notified as possible but just in case people don't get the news a notice at the scheduled location (or in the on-line meeting room) should be posted by an organizer.

• Try to be prepared for no-show speakers - having a standby speaker or the organizer(s) having a back-up discussion available ideally both can turn a disappointment into something really useful.

• Set a Code Of Conduct very early on, this will have to be compatible with the company, or organization, policies but should also reflect the general python policies of:

  • Inclusive & Welcoming - i.e. Open to all levels of ability

  • Non-Discriminatory - i.e. Not permitting any bias based on issues such as sex, race, religion, age, orientation, physical or mental attributes, etc.

• Also try to agree, early on, a name for the user group - often this will be some combination of the letters PUG and the company initials but be aware of the possibility of conflicting with other groups, acronyms, possibly offensive names, etc.

• If you wish to come up with a logo for the group don't forget that you will need permission to use any company or organization logos and the python logo.

• Can you get someone within the company to sponsor the user group to the tune of T-shirts and permission to wear them, or similar, alternatively some groups are willing to pay for their own but would need permission to wear them at work.

• Vary the meeting content and format between sessions - a mix of Formal Presentations, Q&A, Short Presentations, Favorite Library Discussions, Workshops, etc., can be very productive.

• Try to allow a little time in each meeting for calls for presentations, news, appeals for assistance, etc.

• Consider the possibility of internal guest speakers e.g.: from other language user groups, other business groups, etc.

• Consider the possibility of external guest speakers from the wider python community but be aware of confidentiality issues, the need to get permission for the speaker to be on-site, etc.

• If meetings are being recorded, for the archives or for those that could not attend, you must start with an announcement of the fact that it is being recorded this is a legal requirement in most jurisdictions.

• Internal forums are an ideal venue for speakers to rehearse and get feedback on presentations that they are planning on giving to wider audiences such as corporate level, external conferences, etc. note that such often come on tight timescales to consider either being flexible in the schedule, (bumping another speaker with their agreement), or holding a special meeting to allow such speakers to give their presentation well before they need to present it elsewhere so as to allow time for any feedback to be incorporated

• Encourage the presenters to make links to materials used available, ideally in advance of the meeting.

Small Organizations

For small, single site, or only a couple of geographically close sites:

• Face to Face Meetings are probably better

• Try to locate a venue such as a meeting room for such meetings, note that you may have to relocate to fit the size of the user group over time as the membership fluctuates.

• Try to ensure that the venue(s) have the normal presentation tools and reasonably network connectivity

• If the company or organization is spread over a number of geographically close sites it may be an idea to rotate the location between sites.

• Consider if it is possible & practical for people to "remote in" to meetings that they cannot physically attend.

• It can be hard, unless your company or organization is heavily involved with python, to reach a critical mass where you have enough people involved.

Large Organizations

Larger Organizations are significantly different to smaller ones and have some other considerations:

• The majority of "meetings" will, necessarily, be on-line, virtual meetings - consider which technology is available & suitable.

• You will also need some sort of file share facility that everybody in the group has at least read access to and this probably needs to be restricted to people within the company as the content may include confidential information - public shares need to be avoided in most cases.

• Consider using a number of time slots to deal with the fact that not everybody is in the same time zone.

• Recording the meeting will allow people who missed it for whatever reason to watch but:

  • Attendees must always be aware that the meeting is being recorded.

  • There needs to be an accessible file share location, not a public one, that the recording can be posted on.

  • Try to post recordings promptly,
  • Since the recordings are likely to be sizable make sure that you are not going to be exceeding any limits,

  • It is a very good idea to post process the recording to skip any spurious sections so have an organizer with the time and ability to do this - personally I use MoviePy to trim recordings made within Skype for Business resulting an average 70% reduction in size as the post processing compression is more efficient than the real-time.

• If the organization is global try to build a network of organizers around the globe so that meetings can be hosted in the different locations and time slots.