Community Meeting Agenda 9 February 2010

Listen to the Recorded Meeting:
 * 1) Click here to view and/or listen to the recording First enter your name and click "Attend Meeting" The ID number is 9218. The recordings are available by clicking on the "Attachments/Recordings" link.

= Agenda and Notes =

Update!: Current engineering priorities and future backlog prioritization process
Update: As discussed in our last meeting, while we work on a long term solution to share our engineering backlog within the wiki itself, we've created an interim solution to share the backlog, allow you to vote/promote issues so that they are prioritized higher and add new issues. For those who are intrested, the process is as follows:

1. Log on to the FS Developer's Network and create an account (yes, you'll have to create another account... my apologies, but, it's an interim solution)

2. Send email to [mailto:bennettbr@familysearch.org] notifying me that you've created a Developer's Network account.

3. I'll add you to the private Wiki Development Backlog project where you'll be able to see the backlog (once I've added you as a member of the group, you can use the following link to access the backlog in the future:Research Wiki Dev Backlog

Once inside the backlog, note that you can view issues (in list form), vote on issues (by clicking on the subject line link and then using the up or down arrows on the subsequent page) and add issues (by clicking on the 'new issue' tab).

Note that issues marked with the status of "Assigned" have been accepted and are being developed (you can look at the individual issue to see the expected completion date). Issues marked with the status of "Feedback" are issues that we're considering for the next cycle which you may vote on (see voting instructions above).

Also, answers to your questions posted after the meeting are as follows:

1. One concern was that it will be just another site check for information. Currently we have the Wiki, talk pages, and Forums, and this new site will add yet another site that needs to be checked. [Ben Bennett] Unfortnutally you're right (at least for the time being). That said, one of the items that we've added to the engineering backlog is a task to add an extension to the wiki that will allow us to track issues/bugs within the wiki itself.

2. Is DevNet there for everyone to add information, or is Ben the only one who keeps the discussions updated in DevNet? [Ben Bennett] As long as you sign up for a DevNet account, you can view, add, modify and vote on items on the issues list. 3. If the conversation is going on in the Forums, who would take it and move it onto the backlog. [Ben Bennett] Anyone can move the issue to the backlog (ideally whoever sees it first) and then add a reply in the forums that the issue has been added to the backlog with a link to it should the original submitter wish to see the full list. 4. For example, the current Poll in the Forum related to the red links in search results now has 14 votes. Is the voting over? Is this feature/enhancement automatically moved to the backlog? Has it been moved already? Where is it in the priority? [Ben Bennett] Voting isn't over, but, the forums aren't exactly the easiest way to manage the engineering backlog. For now, items will be moved from the forum into the backlog on DevNet where you can vote/promote those items that are of greatest interest to you. Note that the voting functionality is already enabled, however, I've had some problems seeing the voting buttons using IE7/8. You can see them just fine using Firefox. 5. I am concerned that the majority of the backlog will be content backlog and the DevNet tool is only geared toward tracking engineering backlog. [Ben Bennett] Correct... for starters, we'll use DevNet for the engineering backlog. We're looking for other solutions for the content backlog. 6. Wikicode backlog is also another aspect of our tracking needs. [Ben Bennett] For now, I'd propose that we add this to the backlog on Dev net as it's engineering related. To the extent that members of the community can/want to complete wikicoding tasks, they can assign themselves those tasks in the DevNet backlog. If a wikicode task goes un-assigned (for whatever reason) and is voted as a high priority, we can look at having the FamilySearch staff work on this. Open to feedback if you disagree with this approach. 7. We need three backlogs: Content, Wikicode, Engineering 8. From my discussions with Fran, I believe the definitions are as follows: Content = anything that most any contributor can handle; Wikicode = anyone at least a little more technical that can work in Wikitext, create templates, etc.; Engineering = only FamilySearch.org employees can work on. Thomas_Lerman 22:20, 9 February 2010 (UTC) [Ben Bennett] I like your definitions and I think that those are fair for starters.

Summary: Ben Bennett is the product manager for the Wiki and requested this item be added to the agenda. Ben will be joining our meeting and will lead this discussion. For some time now, our wiki user community has been posting bugs, suggestions and feedback to the FamilySearch wiki Forums. FamilySearch Product Managers (who ultimately prioritize engineering work on the wiki), pull data from the forums as well as other sources (e.g. requirements from other FamilySearch.org products and affiliates who want to integrate with the wiki) to create a prioritized list of engineering/development priorities. Engineering work happens in cycles that are approximately 5 weeks during which fixes and features are rolled out as they are completed. Going forward, it's our desire to create a) more transparency in terms of what the current and planned engineering priorities are, b) solicit community input on prioritization of future fixes/features and c) solicit assistance from community members with PHP, Wikicode and other programming experience who desire to assist in completing some of the engineering priorities (thus delivering more fixes/features to the community faster).

Detail: While the long term solution will be to build a series of bots and maintenance pages within the wiki to manage engineering priorities, for now, it's proposed that we use the FamilySearch Developers Network to share and manage the backlog. Here, users can see current issues that have been logged, current priority/status, and users can vote to increase the priority of an existing issue. Users can also add a new issue to the list.

While we will continue to direct the community at large to the FamilySearch Wiki forums to log their issues, for those who are interested in seeing additional detail and assisting in prioritizing and developing future fixes/features, the FS Developers Network is the proposed solution.

By creating an account (sorry, you can't just use your wiki account to log in here - at least not yet), you can see priorities for this current sprint. In addition, I'm working to update the list with all past issues which have been raised/logged. I expect to have this done this week (and you're welcome to add or update with your votes any other issues in the meantime).

Thoughts on this proposed approach?


 * No major objections. One concern was that it will be just another site check for information. Currently we have the Wiki, talk pages, and Forums, and this new site will add yet another site that needs to be checked.
 * Is DevNet there for everyone to add information, or is Ben the only one who keeps the discussions updated in DevNet?
 * If the conversation is going on in the Forums, who would take it and move it onto the backlog.
 * For example, the current Poll in the Forum related to the red links in search results now has 14 votes. Is the voting over? Is this feature/enhancement automatically moved to the backlog? Has it been moved already? Where is it in the priority?
 * I am concerned that the majority of the backlog will be content backlog and the DevNet tool is only geared toward tracking engineering backlog.
 * Wikicode backlog is also another aspect of our tracking needs.
 * We need three backlogs: Content, Wikicode, Engineering
 * From my discussions with Fran, I believe the definitions are as follows: Content = anything that most any contributor can handle; Wikicode = anyone at least a little more technical that can work in Wikitext, create templates, etc.; Engineering = only FamilySearch.org employees can work on. Thomas_Lerman 22:20, 9 February 2010 (UTC)

Feedback Requested: proposed changes to our FamilySearch wiki license
Summary: Ben Bennett is the product manager for the Wiki and requested this item be added to the agenda. Ben will be joining our meeting and will lead this discussion. For background on this discussion, the FamilySearch wiki uses a creative commons non-commercial license vs. the Creative Commons Attribution-Share Alike license which Wikipedia.org and many other well known wikis use. As the hosts of the wiki, we are proposing a change in the licensing of our content in order to allow our community members (and others) greater flexibility in the way that the wiki content is used. Prior to doing so, we want to solicit community input on this planned change. We plan to solicit input from the wiki community at large starting on Wednesday, February 10th - Friday, February 19th via a notice on the wiki home page. After the feedback period is complete, we will communicate the planned decision and appeal process should any contributors disagree with the outcome. Additional details (and links to the exact language for the different licenses) can be found below.

References:


 * 1) Current FS Wiki License: Creative Commons Attribution-Noncommercial-Share Alike
 * 2) Proposed FS Wiki License (pending community input): Creative Commons Attribution Share-Alike
 * 3) General Description of all Creative Commons licenses: Creative Commons Summary - All Licenses

Note that the full legal language of each license is available by clicking on the "Legal Code" link at the bottom of each page.

Detail: FamilySearch originally selected a non-commercial license for the wiki because we did not want a commercial company to be able to put a different face on the content and wanted to keep our content ad-free. That said, as we've looked at ways that other wikis are run, organized and licensed (namely Wikipedia.org ) and considered how our community and FS may want to use content in the future, we think that a license change may be in order. In support of this intention, some research with our legal advisors at FamilySearch has helped us understand why a non-profit, community site such as Wikipedia.org might choose a license that permitted “commercial” use of the content. The legal advisors informed us that “commercial” is associated with anything where money is being charged. The ambiguity of the non-commercial license could place restrictions on the FamilySearch wiki, limiting future use of the content, even for legitimate non-commercial purposes.

Some examples of activities that are not allowed under the current FamilySearch wiki license are included below:


 * 1) I contribute a large portion of information to begin a new article. Others edit the information, but the bulk of the content is still my original work. Later, I want to utilize the information with edits in a class syllabus for a conference. Under the current license, I would not be able to do this as a paid conference presenter. I could use my original contribution, but not any of the updated, current information contributed by others.
 * 2) I am teaching a free family history class, but no Internet access is available at the venue. I want to print copies of a few articles from the wiki for the participants in my class. I need to recoup my copying costs, and so I want to charge a small fee for the copies. It is questionable whether or not this would be allowed under the current license.
 * 3) I am a commercial company and I want to contribute content to the existing wiki, rather than create my own online research tool. I determine that the FamilySearch Research Wiki is the best place to send my customers to get the most current research information. I want to provide links to the wiki on my website to show my customers how the wiki may work with my own products and still provide a unified, good experience for my customers. By linking to the wiki, I will drive more traffic to the wiki and help my customers get the research help they need. Some of my customers may even become potential contributors to the wiki. I cannot do this under the current license.
 * 4) A non-profit entity realizes that some parts of the world do not have access to the Internet. They decide to print relevant articles of interest for those parts of the world, and package them in a small booklet to be sold at cost to peoples in these regions. This would not be allow under the current license.

While the commercial license has been implemented with Wikipedia (see ), it is interesting to note that we have been unable to find any company who has chosen to risk using this license in a commercial way. The general ambiguity of the Creative Commons licenses appears to have limited commercial companies from using the content, possibly due to the potential risk of unclear interpretations of the terms of these licenses.

REdefining role of Moderator
Yes I did emphasize "re".

It is more clear and more obvious there is a need to redfine the term "Moderator".

The role needs to include the emphasis on additional responsibility of "assisting" the contributor including leading the contributors to various tools when asked by email. dsammy 21:10, 9 February 2010 (UTC)


 * Yes, I agree the role of moderator needs reviewing and redefining. --Fran 21:15, 9 February 2010 (UTC)

Stay Informed
Stay informed by visiting the FamilySearch Wiki Forum and by viewing the following pages:


 * Wiki Product Backlog
 * Wiki Known Issues