Wiki Working Group - 6 May 2014
Previous meeting's notes: 4-22-2014
- Christie Koehler (ckoehler)
Agenda / Notes
(JD) Deployment through the paas has been approved by technical owner and security team:
- Question around if the group likes this idea and if it seems feasible from a development standpoint.
- Need someone with community LDAP willing to work with jd to test access.
- jd would create a buildpack, place in github & anyone with LDAP can deploy to paas for development environments (prod discussion to follow at a later date)
- Other alternate options, some sort of script - vagrant image
- What has community LDAP? How does one get this?
- File a bug, sign committers agreement.
- We should identify someone in WWG who is a community member and who plans to do development / submit code.
- Yes, we will move forward with this approach.
We won't go over these in the meeting unless there are question. If that's true, put your questions in the 'Discussion Items' section below.
- Christie triaged the list of open bugs. Here's the remaining list:
- Working on getting bugs into scrumbugs:
Review wiki.mozilla.org scope statement
- Christie clarifies that the statement is as much proscriptive as it is descriptive. It has an element of what the wiki could/should be (vision).
- Agreement to add something about how wikis are a recognized organization tool and using them connects Mozilla to the larger open source/knowledge community and signals its participatory nature.
- Agreement to add something about how there are year and years of project notes, that this is a very useful tool for new and existing community members. "Institutional record."
Review WWG scope statement
- Christie: I like the idea of mirroring the CBT working groups and of being embedded with them as much as possible. What do we do when some of those groups are less active, hard to embed with or disappear all together?
- Group feedback/questions:
- is there too much structure? How do we find people to join all of these committees?
- perhaps one way to look at it is 'areas' that are more fluid rather than committees?
- in a way we have built-in volunteers if we align with CBT structure
- clarify what CBT is (and check to make sure other acronymns are also defined)
Building custom themes means additional maintenance cost. Do we really need a custom theme? Can we put the Mozilla logo on vector and update some of the colors?
What version(s) of MW do we want the theme to be compatible with? I would love to switch the the more modern (non-LTS) 1.22 branch.
- an option is to fit it with sandstone somewhat, but doesn't need to match entirely
- Re Sandstone, From http://www.mozilla.org/en-US/styleguide/websites/community/overview/
"Sandstone is a set of tools to help you make any community site consistent with our current brand guidelines and let visitors know that it is officially part of Mozilla.
At minimum, please include Tabzilla and use Open Sans Light for headers in your designs. You may also use responsive design, a large top promo area and a menu system like the one on mozilla.org and our other sites. The below examples show Sandstone implemented on various community pages. Please note the elements they have in common as well as those that have been customized or embellished."
- Should we have a WikiMo specific logo?
- risk is that this will contribute to the idea that WikiMo is a subset of the project rather than something that encompases the entire project
- maybe the mozilla communities logo?
- let's keep this on the table for further discussion
- related here's a video about how best to work with MoCo creative team: https://air.mozilla.org/how-to-work-with-the-creative-team-by-john-slater/
Getting more people involved
Are we ready to announce at the project meeting and place a call to action? What are blockers to this? How should we direct people? Should we just have them join the wiki working group?
- Agreement that we need a bit more documentation before we open the floodgates.
- Will proceed with interest generated by announcing WWG and scope statements on Monday meeting.
What do we think of following an RFC processes for the big changes we want to make? Something like: https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces
- Agreement to move forward with this approach with the following in mind:
- will need to work to social this process
- will need to reach out to specific individuals and ask them for feedback
- will need to provide clear instructions about how people should provide feedback
- Revised both scope statements and present at Monday's project meeting.
- Start logging tasks in Bugzilla so we can triage in Scrumbugs.
- Move forward with creating buildpack so that we can use pass for development.
At the next meeting we'll incorporate feedback about the scope document and start triaging feature requests into roadmaps.
- Everyone: Please review and comment on draft Wiki style guide: https://cbt.etherpad.mozilla.org/wwg-styleguide
- Hexmode: Talk with wikimedia developers while in Zurich and find out what effort is involved in creating a new, full-featured theme entirely from scratch.
- Christie: incorporate today's comments about scope statement and send out for final review. Plan to publish in time for Monday meeting.
- Everyone: Start adding tasks to bugzilla under Websites: wiki.mozilla.org