User:Mconley

Meilani Conley

Meilani Conley is a second year Instructor in the College of Business and Computer Science at Southwest Baptist University in Bolivar, MO. She teaches various Computer & Information Sciences (CIS) courses as well as Web Design courses. The CIS department provides three majors: Computer Science, Computer Information Science, and Web Systems and Design.

Meilani Conley's scholarly interests span software engineering, computer science educational techniques for K-12 and college level recruitment, and web design development. Prior to coming to Southwest Baptist University, Meilani Conley spent 5 years in industry working for a healthcare IT company and in government contracting.

In her spare time, Meilani Conley enjoys local and foreign mission projects, reading books (certified bookworm), writing, singing, and watching sporting events.

Intro to IRC Activity

How do people interact?

At first it seemed as though everyone had short interactions in attempts to get a better feel for the chat environment. Eventually, all the participants started to open up and test the basic features available through meetbot.

What is the pattern of communication?

The communications were more facilitated by Heidi, but all the users were trying to get use to the formatting and commands available. I truly believe as we get to know one another and commands become more fluid that communication will increase.

Are there any terms that seem to have special meaning?

The #info was used to format messages and add them to the minutes log for the IRC meeting. I enjoyed using this feature and switched between using #info and casual conversation in the webchat.

Can you make any other observations?

There are different options in formatting messages that I plan on experimenting with in the future.

IRC Meeting 1

Discussion of HFOSS projects

The conversation talked about the projects of interest for each participant/contributor. The HFOSS projects I am interested in are OpenMRS, Sahana, and Ushahidi. The focus of each of these groups align with student interests in our department.

As I have observed and learned more about the different HFOSS projects, the one that really resonates is the Ushahidi project. The mission of Ushahidi is "Monitoring political unrest, measuring the impact of natural disasters, uncovering corruption, and empowering peace makers. The people who use our tools change the world.". The efforts of this project mimic those of the Sahana HFOSS project whose main focus is a warning system.

Anatomy of a FOSS Project

Sugar Labs

Communities

Activity Team - Detailed review of project, tools and links to be successful, leadership roles, code reviews, and so much more. The level of detail and guidance is appropriate for the focus of this team.

Development Team - Provides links to bugs to allow contributors to help fix issues, shows platform release cycles, code reviews to give users an idea of what to expect, and project ideas that discuss current and future innovations.

Documentation Team - Provides reference manuals and tutorials for users/contributors.

One of the common characteristics of each team list above is that they have a focused mission that defines the work they do and what they are about. Each team provides the necessary level of detail to give an overview of the projects, issues, and leadership involved with the project. The differences can be noted in the observations above.

Tracker - The Type/Categories available are Defect or Enhancement. The following information is provided for each ticket:

• Unique ticket number
• A brief summary about the ticket
• Status (accepted, assigned, closed, new, and reopened)
• Owner
• Type (defect, enhancement, or task)
• Priority (Immediate, Urgent, High, Normal, Low, and Unspecified by Maintainer)
• Milestone (Unspecified and 0.100.0-0.102)

Repository - Appears to use a local repository.

Release Cycle - At the beginning of the release cycle the roadmap update is refreshed by the release team. The Roadmap update is a vital part of the release cycle.

Sahana

For example, are there any commonalities? Is there something distinct for each type of contributor? How is this structure different than the one you found on the Sugar Labs website?

Developers - Guidance notes, tasks available including easier bugs to fix, all open bugs, CI server results, Projects, and BluePrints

Testers - Provides non-technical users ability to contribute to the Sahana project via testing and documenting test cases. Developer Guidelines are available.

Designers - Unique group that focuses on the Graphic Design portions of Sahana. The designer would be working with HTML and CSS (and others if desired). Developer Guidelines for Themes and Usability are available. They focus on the following:

• The Application
• The Websites

HFOSS Project Differences - Sugar Labs versus Sahana:

• Sahana is more informal on the Developer's page.There is no specific mission for each team. The leadership is not identified like it is on the Sugar Labs website. On Sahana you can subscribe to the results of the tests.

• There is a Contribute Q & A on the Sahana Testing team. There is a Designers team that takes care of the graphic design choices for the applications and websites.

Tracker

How is the information from Sahana different than the information found on the Sugar Labs tracker page?

• The Sahana site is more simplistic
• Modifiable query, but no initial sorting features for tickets
• Only lists open tickets
• Most recent tickets are listed first
• Tracks creation date of tickets,
• Components involved with the ticket are listed
• Version of the ticket
• Priority settings are different

Ticket Categories/Types:

• Unique ticket ID
• A brief summary about the ticket
• Components associated with the ticket
• Version (Trunk, test)
• Priority (critical, major, minor)
• Owner
• Status (accepted, assigned, closed, new, and reopened)
• Type (defect/bug, enhancement, or task)
• Date of creation

Repository - The repository is a web-based repository.

Release cycle - Describes the backend solutions, modules that are stable and those still in Beta testing. Breaks down information into milestones and the Framework Features (hours contributed for each piece and the Mobile Client).

FOSS Field Trip

• Area of Interest: Music

• Located 20 projects in the Music category

• Number of Programming Languages Used: 15

• Top 4 Programming Languages Used: C++, Java, C, and C#

Project Status Definitions:

• Inactive - No longer being used or relevant.
• Mature - Depending in the system context this status means the software has a level ready enough for testing.
• Production/Stable - Means the product is ready is for deployment. Released the application to the public since it is stable.
• Beta - The first release available to the public. The developers have tested and ready for feedback from the public.
• Alpha - First phase to begin software testing for the application. The software is being tested by the developers during this phase.
• Pre-Alpha - Pre-alpha refers to all activities performed during the software project before testing
• Planning - Proposal for the product that the developers hope to create.

Project Comparison

• Project #1: Midi Sheet Music
• Project #1 Status: Production/Stable - Ready to be deployed and ready for use.

• Project #2: Canticum - Visual Network Music Player
• Project #2 Status: Planning - In the developmental design phase, allowed to browse code.

• Production/Stable projects are typically the most used. You can tell the usage by the number of downloads as well as the reviews.

Music Project Review: Midi Sheet Music

• What does it do? - It plays MIDI music files while highlighting the piano notes and sheet music notes.

• Project Programming Language: C#, Objective C, and Objective-C 2.0

• The users that are most likely desiring to use this project are those interested in instrumental and/or musical accompaniment, rehearse musical pieces, and learning how to play the piano and/or read music. The type of usage is based off of user reviews. The users describe how they are using the product.

• Most Recent Update: 07-31-2013

• Activity Level: Active project, there are recent tickets being logged and discussed. Also, there are downloads from this week which indicates users are still interested in using the product.

• Number of committers: Only one committer

• Personal Comments: I would use this product as I have a deep love for music and learning/composing music. This is a solid product that has great reviews and user feedback to verify product stability.

Explore Mifos

• Main Programming Language Used: Java
• NLOC: 2,673,467 million
• User & Contributor Locations": Unknown, would not display in Chrome, IE, or Firefox
• Number of Languages Used: 19
• 2nd Highest NLOC: XML
• Highest Comment Ratio for a Language: Perl
• Average Number of Contributors in last 12 months: 3
• Top Contributors Project Involvement:

    Krzysztof Kaczmarczyk - 2 years
    jakub_slawinski - 5 years
    Jakub Kondrat - 7 months

• Average number of commits (over 12 years): 2.5 commits

PART 2: Project Evaluation Activity

Mifos_Project_Evaluation.xlsx‎

Blog Activity

First Blog Entry

FOSS in Courses Activity

Identify activities or topics that you are interested in within your HFOSS project of interest. This can be a rough list and can serve as the basis for identifying possible class activities/topics.

HFOSS Project: Sahana

Activities/Topics of Interest:

• Mobile App development - how do we adapt this to multiple/diverse communities? How do we design for color palettes for certain communities? How do we account for cultural differences?
• Crisis system - expanding this concept to warn communities of militia, invaders, disturbances, etc. Studying past disasters and/or issues to see how Sahana can address that area in the future.

HFOSS Project #2: Ushahidi

Activities/Topics of Interest:

• Water Tracker - does this track clean and sources that need to be filtered?
• Interactive mapping - how does this? Can you choose a specific country? How is testing performed for the mapping.
• Crisis Warning system - How can this be used in violent areas to track deadly and/or violent occurrences, uprisings, etc.?

FOSS Course Brainstorming

• Sahana Mobile App - our students would benefit with combining design principles, coding, and cultural diversity.
• Ushahidi Interactive mapping - There is a testing environment that allows students to see their tests and contributions in real time.

• Help Resources: I found multiple blogs, entries, and links that provide resources on both projects of interest. I do believe there are pieces of both the Sahana and Ushahidi project that would be a great opportunity for my students.

Bug Trackers

PART 1 - Bug Reports

Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.

• ID - Ticket ID numbers
• Sev - Severity: This field describes the impact of a bug.

    Blocker:Blocks development and/or testing work
    Critical:Crashes, causes loss of data, or is a severe memory leak
    Major:Major loss of functionality - menu item broken, data output extremely incorrect, or otherwise difficult/useless to use.
    Normal:A minor part of the component is nonfunctional or broken.
    Minor:Minor loss of function, or other problem where easy workaround is present.
    Trivial:Cosmetic problem like misspelled words or misaligned text.
    Enhancement:Request for a new feature or functionality.

• Pri - Priority:This field describes the importance and order in which a bug should be fixed. This field is utilized by hackers to prioritize their work to be done. While each term has a description, it is important to note that priority is highly subjective, and bugs can move up or down the priority scale based on subjective questions like 'would we be embarrassed to release the software with this bug.'

    Immediate:This bug blocks development or testing work and should be fixed ASAP, or is a security issue in a released version of the software.
    Urgent:This bug blocks usability of a large portion of the product, and really should be fixed before the next planned release.
    High:Seriously broken, but not as high impact. Should be fixed before next major release. Frequently includes cosmetic bugs of 
    particularly high visibility, regressions from functionality provided in previous releases, and more minor bugs that are frequently reported.
    Normal:Either a fairly straightforward workaround exists or the functionality is not very important and/or not frequently used.
    Low:Just not all that important. Rarely used in GNOME.

• OS - Operating System associated with issue/ticket
• Product - The product specifically being affected.
• Status - The current status of the ticket.

    Unconfirmed (UNCO): Unconfirmed issue/ticket. Needs review.
    NEW: Newly created ticket/issue, validated that this is an issue.
    Assigned (ASSI): The ticket has been assigned to someone to be completed.
    NEED (NEEDINFO): Requires more information from the reporter to be completed/investigated. 
    REOP (REOPENED): Issue that was closed, but solution not correct. 
    RESOLVED: A resolution has been taken, and it is awaiting verification by QA. From here bugs are either re-opened and become 
     REOPENED, are marked VERIFIED, or are closed for good and marked CLOSED.
    VERIFIED and CLOSED:  Indicates that a third party has checked to see that a bug was properly resolved.

• Resolution- Indicates what happened to this bug.

    FIXED: A fix for this bug is checked into the tree and tested.
    DUPLICATE:The problem is a duplicate of an existing bug. Marking a bug duplicate requires the bug# of the duplicating bug and will at least 
    put that bug number in the description field.
    WONTFIX: The problem described is a bug which will never be fixed.
    NOTABUG: The problem described is not actually a bug, but a design choice of some sort.
    NOTGNOME:The bug is either not in a module that is part of GNOME, or is caused by something outside of GNOME that cannot be worked 
    around or otherwise resolved by the GNOME application.
    INCOMPLETE:The bug lacks sufficient information to be fixed, and unlike NEEDINFO, no answer is possible or expected.
    INVALID:This bug is in some way not valid - usually used when INCOMPLETE or NOTABUG just don't quite fit.
    OBSOLETE:This bug is in an old (obsolete) or unmaintained version. This includes GNOME 1.x. 

• Summary - Brief description of the issue.

Definition Discovery: Used Reports > Explanation of various terms and fields > Bug Fields

Ticket/Bug Order:

1. Unconfirmed

2. New

3. Assigned

4. Reopened

5. Need More Info

What is the meaning of the shading of some bug reports? Indicates enhancement tickets. What is the meaning of the colors used when describing a bug (red, gray, black)? The red means the severity is critical, gray means the severity is an enhancement, and black classifies all other severity levels.

• Bug/Ticket Selected: Bug 349190 - Don't hard-code colors
• Bug Submission Date: 2006-07-29 16:14:31 UTC
• Most Recent Discussion: 2014-06-15 16:46:14 UTC
• Is the bug current? NO
• Is the bug assigned? To whom? Yes, Baobab Maintainers
• Proposed Resolution/Process: I would need to see if I could recreate the issue in multiple tests, verify that the bug is not related to Bug 601370 per the comments. Once I rule out whether this is a duplicate ticket or not then I would triage the situation.

Part 2 - Collective Reports

Click on the “Reports” link on the top of the page. Number of Bug Reports Opened (last week): 345 Number of Bug Reports Closed (last week): 481

• Opened versus Closed: There were more bugs closed than opened last week.
• Top Three Closers - Important to know as you can follow their contributions, ask questions, review tickets, and get support when needed as they are a frequent/core contributor.

Magdalen Berns (irc magpie) Bastien Nocera Milan Crha

• Top Three Bug Reports: The top reporter is the same as the top contributor, but the other two are different (yes, overlap exists).

       Magdalen Berns (irc magpie)
       Jim Nelson
       Debarshi Ray

• Top Three Patch Contributors:

       Jonas Danielsson
       Cosimo Cecchi
       Ondrej Holy

• Top Three Patch Reviewers: One person overlaps with closers and bug reporers, but the others are different.

       Florian Mullner
       Sebastian Droge (slomo)
       Bastien Nocera

• No overlap in top three patch contributors and reviewers

• Plot the Severity of each Version of the Accessibility features of Empathy.

 Accessibility Features Chart

• What other reports can you generate? Countless, you can be as broad or as granular as you want.

POSSE 2014-11