User:Sdz/Summer Project Ideas

Implementing the Semantic MediaWiki plugin for use within Fedora QA
An initial attempt of using semantic infrastructure for testing purposes has been run during the Sugar on a Stick test day on 2009-09-03. A day before, Mel Chua, James Laska and I sprinted on getting a test instance up on the publictest6 wiki. The process was logged [1] and allowed testers to use the semantic wiki as instructed [2], for the first time, resulting in a number of entries which are still available [3]. However, since we worked the whole system out in a very limited amount of time - basically just one sprint - it didn't work as smoothly as it could have. Obviously, it also lacked a lot of polishment, that could have been possible if planned over a much longer time. Consensus was, though, that the idea of using a semantic mediawiki instance should be explored further and possibly used at some point. The general concern was the time needed to document and implement the system initially. As part of a possible summer activity, working on such a task would not only remove this barrier, but also significantly benefit Fedora, since one of the biggest advantages of the semantic concepts is its ability to organize and structure results much better than compared to, say, a wiki table.

[1] http://meetbot.fedoraproject.org/fedora-qa/2009-09-02/fedora-qa.2009-09-02-14.14.html [2] https://fedoraproject.org/wiki/Test_Day:2009-09-03_SoaS#Add_your_results [3] https://publictest6.fedoraproject.org/wiki/Category:Test_result


 * Semantic mediawiki (SMW) seems like one of those things that would be cool to do, but which nobody has ever had time to really work with; jlaska and adamw would be good people to ask more about this, and other opportunities in Fedora QA, as you've noted above. (I know you're interested in picking up skills that would also help your work in Sugar Labs, and I see QA as one of the biggest things that the SL community is lacking right now, so this seems like a good thing to learn if you have the chance this summer.) Mel Chua 06:13, 3 January 2010 (UTC)

Working on the LiveUSB Creator
Luke Macken mentioned on-list [1] that he wouldn't mind having help on doing builds for the liveusb-creator (for example for the windows version). A possible summer activity might be working on the project directly. Since the livecd-tools package is currently unmaintained and further use cases would be more fitting for liveusb-creator (as mentioned in bug reports [2]), this - as one of Fedora's key deployment methods - could be an area for further improvements. However, it'd require me to learn and dive more into Python, which would enable me generally apply this knowledge, though. Additionally, it'd be benefit not only Fedora, but also projects such as Sugar on a Stick and other Fedora-based spins and remixes, which are presumably using liveusb-creator for an easier distribution.

[1] https://www.redhat.com/archives/fedora-olpc-list/2009-November/msg00040.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=448030

Helping to maintain LiveCD Tools
The livecd tools are crucial in terms of creating and deploying Fedora. They're currently unmaintained, though. The package itself contains not only the livecd-creator which builds Fedora's live builds, but also livecd-iso-to-disk, a command line tool to create a liveusb key. Working on the package would require a significant learning effort to understand the ways the kernel, squashfs and other elements work together. On the other hand, having the tools themselves under some kind of maintainership, be it temporarily, would help to ensure an ongoing quality, even with upcoming changes to system components which might affect the functionality of the tools.


 * What happens to maintenance of the liveCD tools once the summer is over and you go back to school? How could you make sure that even a temporary maintainership would have a lasting effect (that is, once school begins in September, how will we be in a better position than we are in now)? Mel Chua 06:14, 3 January 2010 (UTC)

POSSE Infrastructure Easiness
After the first POSSE, Mel Chua created a follow-up with further ideas how to improve the POSSE program as it moves on. An idea was POSSE-in-a-box, intended as a way to make it radically easier for interested people to run a POSSE. Whereas the original POSSE included the manual setup of various VMs as well as the creation of a specific remix, this could happen automatically, saving organizers a lot of time and making it generally easier for people to actually run a POSSE. Ideally, it would be possible to create the required infrastructure (possibly even giving organizers the possibility of creating their own, adjusted version of Fedora). This doesn't stop at this point, though, but could be usable to enable colleges and universities to get their hands on their own, entirely open source software stack - for example for collaboration, but also for interacting with the community.


 * Between the two ideas in this section, I think this one is higher-leverage. Mel Chua 06:15, 3 January 2010 (UTC)

Teachers Open Source Summer Experience
The idea of holding a POSSE - just instead for teachers - basically implies using the same concept for a somewhat different target group. Whereas POSSE targets universities and their professors, it's already moving in a direction towards having more people running local POSSEs. As such, several customized versions for teachers - instead of professors - might be organized. Starting already at a lower level, those events would probably target one town and thus require a lower budget. The content within such a concept would focus obviously on promoting the advantages of the open source way of working (one might also think of open content, reaching out to collaborating and remixing work), but also talk about concrete solutions, such as the Sugar Learning Environment for younger children. If in-class usage or local deployments evolved from this kind program, the community would profit and the original POSSE idea would be supported through an earlier start of conveying open source concepts.