W3Cinfrastructure

NOTE: This page was used as part of the development of W3C Community Groups. It may no longer be maintained.

See also W3C_CG_Infoarch

Scenarios

• People will propose ideas in the Community Forum. Others will comment. Ideas with enough support will lead to the creation of a Community Group.
• People will view existing Community Groups, express support for creation of groups, or join groups. The support for new groups may not happen inside W3.org infrastructure, but W3 needs to be notified.
• Joining a group involves authorized parties making IPR commitments. These commitments will be archived. There are also IPR commitments recorded when a group wishes to finalize a document. Leaving a group may also have a IPR implications (depending on when the party leaves).
• People will hold discussions in community groups, create and edit documents, and comment on documents. These community groups may be inside W3.org infrastructure, or have their own autonomous infrastructure, but for IPR reasons this infrastructure must be monitored.
• Business groups will likely be created through different means, but the base infrastructure will be similar. There will need to be payment collection and also connection between joining and payment.
• Members and other organizations will want by-organization views.

Goals

• Functionality
  • Provide a core set of tools for collaboration on documents: editing, communications, tracking, voting.
  • Augment the W3C toolkit to include microblogging capabilities.
  • Provide interface for listing groups, proposing groups, joining groups, and recording IPR commitments
• Usability
  • Ensuring the user interface is simple and integrated
  • Enhance people's ability to customize their W3C experience, which will be increasingly important as the number of people participating grows; we are less likely to know how to meet expectations with prepackaged views.
• Scalability
  • Creation of the base infrastructure needs to have minimal staff involvement in order to scale. This will involve further tool integration and more automation.
  • Further down the road, analytics will help us maintain a larger collection of groups and determine which groups are successful or not. This is particularly needed with community groups where staff should not have to be present.

Non-Goals

• While educational materials are important to the success of the project, they are out of scope for the infrastructure requirements.

Primary needs

1. User interface design, style, graphics expertise. Workflow-based design approach expected.
2. Programming for integration. Software engineering skills, html/css/js, php, sql, linux. Nice to have: general knowledge of web technologies, apache, mail servers, perl, java, python

Functionality

Each group must have a public and non-public communications channel

• Non-public is "participants + W3C Members + Team"
• By default, we'll use mailing lists with acls for the non-public.
• Some tools (e.g., a microblogging tool) might also have the capabilities for non-public, but we won't rely on that to start.

IRC

• Public channel

Wiki

• MediaWiki. Check with Jean-Gui about skins related to site redesign

Not critical for launch:

• Spec editing in Wiki to HTML automation with bibliography database)

Mailing list archives

• Hypermail + hypermess
• Smartlist manages accept/distribution list
• NOTE: Auto creation assumes a shortname proposed when the group is created; need to check if shortname in use.

Blog

• Word Press (likely). Possibly with BuddyPress. Status.Net also has a wordpress plug-in for wordpress integration.

Microblog

• We don't have one installed; could be status.net
• Aggregation of blog comments and tweets (both on Twitter and federated systems like Identi.ca-ca) should be integrated and copied to listserv, use a mix of ActivityStreams, Twitter API, and Facebook Platform app.

Polls

• WBS
• hashtag voting (see socialcast)

Tagging

• None currently. Would be available in microblog.
• Hashtags/tag for each working group when chartered or community group started
• tags could allow blog comments to be aggregated.
• hashtags could allow tweets from status.net and twitter to be integrated into W3C work..

Join/List/Leave/Recording IPR commitments

• We will modify our existing commitment system IPP. Dom and Ian will do the modifications. Notes:
  • CGs and BGs treated the same except for group type
  • Will need modified join page.
  • Will need modified status page (no exlusion, no disclosure, keep addl licensing info).
  • Will need new final text commitment form
  • Will need new pages showing commitments over specs (since just based on final text commitments). Will need to display which people who signed the CLA have not yet made the final specification commitment.
• Our expectation is that the individual signing the agreement has their organization's authorization to do so. We will do the same for Members and non-Members. For Members, we will notify AC Reps when an employee joins a CG or BG.

Group databas

• dbwg. Note that we need to be sure to have individual/org association
• Will need for groups the following data:
  • Title
  • Shortname. We will need a database of shortnames for groups and to avoid collisions.
  • Scope (paragraph(s))
  • Whether it will produce reports (boolean)
  • Current state: Proposed; Pending Approval; Exists; Closed
  • List of parties that supported it and date of support
  • Creation date (which is the date of transition from pending approval to exists)

Issue Tracking

• Tracker

Version control

• Mercurial. Systems team has chosen this over Git.
• There seems to be some preference for Git amongst developers now.

Bridge / Zakim

• For business groups can use bridge resources at no extra cost. Limited to BGs due to current costs and capacity.

Usability

Style

• Need community group branding, i.e. a logo that can be put on indepedent websites.
• Need modern, simple, coherent styles for all interfaces.

Nice to have but not critical for launch:

• Reskinning WBS

Blog and microblog

• Improve signal to noise ratio in blogging by having wordpress tightly integrated with groups and users.
• Use blog to implement W3C Forum.

Mailing list archives

Nice to have but not critical for launch:

• Web view to collapse/expand threads; reply from browser.

Personalization

Nice to have but not critical for launch:

• Dashboard view with social features, messaging, IPR commitments, with a full-featured feed (i.e. ActivityStream) of activity, ideally including even things like wiki edits and tweets of member.

Scalability and Integration

Accounts

• Account creation that has no staff involvement [done]

The following are not critical to launch but will be helpful over time:

• Ability to import and export your W3C profile.
• OpenID support (so that people have one less thing to do in order to participate, namely create a new account).

Group creation and management

• Group creation Web-based wizard for all types of W3C groups. (This can be further automated later but initially used by hand.)
• Admin view of all groups and what resources are associated with them.

Microblog/mailing list integration

• Account-level integration done (LDAP)
• Will seek minimal integration: skin + autocreation of group space.
• integrate blog and listserv

Service APIs

• Access to data related to group tooling

Blog

• CSS skin
• Use of calendar plug-in

Wiki

• Not anticipating skin at launch

PHP

• Will need generic PHP (likely smarty) templates for IPP

IPP

• New join pages
• Queued join request mechanism for all groups

Publication information

• We are asking for editors today but not using that information yet.
• We will need a database of short names to avoid collisions. Legal short name should be at least 3 characters and not already be in use. We will build our database from TR.rdf as well (and will need to keep the short name db updated as TR.rdf evolves).

Analytics

Nice to have but not critical to launch:

• Add some analytics on WG performance, contributions, speed see sociological work by Ben Nyugen on W3C process

ACL requirements

• Internal defined to be 'group participants + those with Member access + W3C staff'

Blog

• Expected to be primary way to announce news to world.
• Therefore: Group write, public read.
  • Current set up is "anyone can comment" even without a W3C account.

Mailing lists

• public-foo (read all, write all). Public archive.
• public-foo-contrib (read all, write participants). Public archive.
• internal-foo (read participants+member+team, write same). lists.w3.org/Archives/Member/internal-foo with custom ACL
• internal-foo-contrib (read participants+member+team, write participants). lists.w3.org/Archives/Member/internal-foo-contrib with custom ACL

Wiki

• Default is to give each group a public wiki: Group write, public read.
• BGs may request internal wiki: Group write, internal read. That one will have a different name (e.g., foo/wiki-internal).

Tracker

If the cost of creating an "internal" ACLed tracker is low, then:

• CGs: Group write, public read
• BGs: Group write, internal read

Otherwise do BGs same as CGs.

Microblog

For Community Groups:

• Two modes of communication; default is "public"
• People can select "group only" as well.

For Business Groups:

• Two modes of communication; default is "group-only"
• People can select "public" as well.

Version control

• Group write, public read. May have several instances per group.

Past notes

• New standards infrastructure page