5: # Google Code-In (GCI) project ideas
7: ## Introduction
8: For the application for [Google Code-In 2012](http://code.google.com/opensource/gci/2012/index.html), and as a starting point for people who want to start working on NetBSD, here is a list of tasks to be fulfilled.
10: All the tasks should be completable within hours or up to three days. To get an idea of how much a single task should be and what kind of they could be, look at [this page](http://code.google.com/p/google-code-in/wiki/GCIExampleTasks).
12: Even if you don't want to attend the Code-In, you can use this as a starting point. In most cases, the work needs some research in order to be completed. Just write a mail to one of the [mailing lists](http://www.netbsd.org/mailinglists/ you think is suiting (if you don't find any, just pick netbsd-users) and ask for more details.
14: We will provide a [Virtualbox](https://www.virtualbox.org/) image for testing, such that you don't have to spend time on installing the system when you want to complete a task where you need NetBSD running.
16: Previous events by Google: [Code-In 2010](http://code.google.com/opensource/gci/2010-11/index.html), [Ghop 2007](http://code.google.com/opensource/ghop/2007-8/)
18: Previous organizations accepted for Code-In: [Code-In 2010](http://www.google-melange.com/gci/accepted_orgs/google/gci2010) [Code-In 2011](http://www.google-melange.com/gci/accepted_orgs/google/gci2011)
20: There is [information from Google](http://code.google.com/p/google-code-in/wiki/GCIMentorInformation2012) about what is suitable as a task for Code-In.
21: The most important part is to make the task easy enough: It should take approximately two hours of an experienced contributor to complete a single task. There are no difficulties, all tasks should approximately have the same difficulty.
23: ## Code-In 2012
24: Code-In is running till January 14th. This site is *not* up-to-date, as several of the tasks are already solved or not doable in this way.
26: ### Lessons learned so far
27: The effort needed for Code-In struck us unexpected. There were several things to be learned about Code-In and about the kind of work that can be done in the scope of Code-In.
29: #### Coding tasks are interesting
30: The students are mostly interested in coding tasks. They do *not* want to write documentation, and they don't want to research things.
31: With coding tasks, students would even spend more time on a task than they would do with something else, and maybe even stick to that task when GCi has finished.
33: #### Add maintenance tasks
34: Another kind of task which was often claimed were the ones about maintenance jobs, in this case conversion of articles from XML to Markdown. They're easy to do, but require a lot of effort - suitable for GCi.
36: #### Have a clear outline of the task
37: Tasks with an unclear description often led to results which were not as expected. Students of this age are more used to have a task which has a clear result, and not something open.
38: Though there were some good results, it's still difficult to understand the tasks and sometimes the tasks were only solved with the second or third approach.
40: #### No creative tasks, but design tasks
41: Don't do creative tasks, i.e. creating images. On the other side, the design or layout tasks went very well - so if you want to know how a student would imagine the interface for a program or website or book format you need, then make that a task - but be clear about the results and *what* you expect.
42: You should have thought yourself about how you would do this in advance, such that you can explicitly state what requirements the task has. You'll get nice results with new ideas.
44: #### Watch out for plagiarism
45: Especially in the research or documentation tasks, you have to be careful about plagiarism. Several students just copied texts from other sources and tried to submit them.
47: #### Don't add extra requirements
48: When the student has to download or configure extra requirements first, the task gets much harder. You should not add tasks which rely on src, pkgsrc or pkgsrc-wip or whatever large or difficult extra things to do before being able to work on the task.
50: #### Make tasks small projects
51: The coding parts are more appealing when they are small autonomous projects. The tasks involving creating your own binary had a larger acceptance than the once which were about fixing bugs of existing programs.
52: You can and should tasks for small programs even if you only want them for *research*, i.e. you want to look at the possibility of a larger project involving this. Even if the task is about another project, but which would or could add benefits for NetBSD, it is possible.
54: #### Make stand-alone projects
55: This is not the same as *making small projects*. The described small projects should be in such a way that you can run them on any operating system and they don't require a speical setup to be written, i.e. many preinstalled packages.
56: The students are most likely not running NetBSD, and forcing them to install NetBSD, install some pkgsrc packages and spend time configuring the system discourages doing a task.
57: Even the Virtualbox images were no great help for some of these tasks.
59: #### Combine tasks to a larger project
60: Maybe contrary to *making small projects*, tasks should have a connection. Students are more engaged if they did something, and when approving the work you already point them to other tasks which are similar to the one they just did, or work together with this one.
62: #### Be clear about your expected formats
63: You should be very clear about the formats you expect for input! If there is an image, tell t hem to upload the "sources" (gimp xcf file or so); if there is a text, it should be plain-text; if it is a program, the final submission should be an archive with the code and not a link to github.
65: #### Stay in touch with the students
66: The best way of communication with the students is via IRC. Everything else is too slow, and when a task is meant to be 48 hours, but half of the time is spent waiting for communication, the task is likely to fail or waste student's time.
68: #### Look into the tasks yourself before submitting them
69: Though it might be charming - when you want students to fix a PR, you should look at the bug yourself and have a slight idea how to fix it before submitting it. There was a task which was not possible to fix (for the student) and was duplicate. And the students might have questions and then having to research things yourself before you can help is not good.
71: Even with all the other tasks, you should have an idea what you want, and what effort it requires. There were some tasks which resulted in much work though they seemed easy in the beginning, while other tasks stated as difficult could be performed within a few minutes.
73: #### Don't underestimate the required effort!
74: You should *not* underestimate the effort needed by Code-In.
75: On the one hand, when you're young, you're not as patient as later. Waiting several hours to get a task confirmed is a lot of time in a student's mind.
77: On the other hand, there was a great run in the first week of Code-In. You have to read several tens of mails every hour, especially in the beginning.
79: When a student needs help, you have to care for him and help him with that, even with configuring the system.
81: ## Goals as stated by Google
82: 1. **Code**: Tasks related to writing or refactoring code
83: 1. **Documentation/Training**: Tasks related to creating/editing documents and helping others learn more
84: 1. **Outreach/Research**: Tasks related to community management, outreach/marketing, or studying problems and recommending solutions
85: 1. **Quality Assurance**: Tasks related to testing and ensuring code is of high quality
86: 1. **User Interface**: Tasks related to user experience research or user interface design and interaction
88: ## Used tags
89: If you want to search for a tag, just search this site for "Tag: $TAGNAME".
90: Used tags are (categories are not tagged):
92: * *man* - tasks related to writing on or working with manpages
93: * *network* - tasks related to networking (including firewalls)
94: * *system* - tasks related to the system itself, either kernel or system level things
95: * *service* - tasks involving services running on the system (as compared to *system*)
96: * *overview* - tasks related to getting and documenting an overview
97: * *howto* - tasks involving the creation of a howto
98: * *comparison* - tasks involving the comparison of different solutions
99: * *research* - tasks involving active research by the student
100: * *ui* - tasks involving the user interface (mostly graphical)
101: * *graphics* - tasks related to creating graphics
103: ## Prerequisites
104: Altough there are several tasks involving prerequisites, you should read the text for the amount they are necessary in. Maybe there is a Latex prerequisite, but we could provide you with the Latex knowledge you need to fulfill the task.
106: For all the tasks involving prerequisites, you should bring in some experience in this field (like typesetting at all for Latex, and minor or very small coding work in the required languages for the coding tasks). We will answer you questions regarding the actual coding, so don't hesitate to ask for a task when you do not fully fulfill the prerequisites.
108: ## Proposed tasks
109: ### Documentation
111: * **Task: Describe the format of usermgmt.conf**: The file usermgmt.conf contains default values used by user management tools (like useradd(8)). But currently, the manpage usermgmt.conf(5) contains only a description of the fields, but not the format of the file itself. So review code about what is possible (spaces, tabs, etc.) and create an EXAMPLE section.
112: The file can be seen here: [usermgmt.conf(5)](http://netbsd.gw.com/cgi-bin/man-cgi?usermgmt.conf+5+NetBSD-current)
113: *Tag*: man
114: *Tag*: system
116: * **Task: Create an overview of NetBSD documentation**: NetBSD has a variety of documentation stored everywhere in the web. On the one hand, there's the website with single articles, the NetBSD Guide, the pkgsrc Guide, documentation in /usr/, the NetBSD wiki, some important mailing list posts, manpages, other mdoc documents, something stored inside the code, etc.
117: In an attempt to gather documentation for NetBSD and provide a nicer entry point for beginners, this task is about gathering the points where documentation lies (with the full path), what language it is written in, what it is about (just a rough overview), and how much it is.
118: For the final goal, see [this mailing list post](http://mail-index.netbsd.org/netbsd-docs/2012/09/20/msg000295.html).
119: If you want to do this task, get in touch with us such that we can provide you with basic information where to start.
120: *Tag*: overview
122: * **Task: Howto: How to get a graphical environment on NetBSD**: NetBSD is a very sleek operating system, delivering an X server (and the mandatory twm), but nothing else. As most people don't like twm, they install another graphical environment.
123: But how do you do so?
124: This task is about creating a howto to install graphical environments after the installation. You should provide screenshots or screendumps (when still being on the console) and describe which configuration files have to be modified, which packages should be installed, which are there after the instalation and which can be added afterwards (special editors, etc.), and so on.
125: The package light-desktop should be stressed in this documentation.
126: *Tag*: ui
127: *Tag*: howto
130: * **Task: Create an overview of the NetBSD server layout**: If you're on a NetBSD mirror, after traversing into the tree you'll see various directories that seem to do the same.
131: You have to traverse the directories of a NetBSD server (ftp.netbsd.org might be the best one, as it is *the* reference), find out which directories have which meaning, and document that. In the end, you should think about a good ASCII representation of a directory tree and realize it.
132: *Tag*: research
133: *Tag*: overview
135: * **Task: Create an overview of the NetBSD releases**: As every project with release engineering, it is difficult for a beginner to know which releases are the current ones, how long will a branch be supported, what are the actual branche names and what is the actual change in a minor or in a major version, what about binary compatibility, and where can I get information all in all?
136: This task is about writing a small article explaining the release engineering of NetBSD.
137: *Tag*: research
138: *Tag*: overview
140: * **Task: Create an overview of the NetBSD src layout**: There is the manpage hier(7), which describes the directory layout of a running NetBSD system.
141: To make it easier for beginners to find things inside src, an equivalent document for the sources of NetBSD.
142: Even if you're not fond with mdoc, researching this and gathering the information (e.g. in plain ASCII or markdown) would be a great benefit, and somebody who likes mdoc can then convert it to a system manpage.
143: *Tag*: research
144: *Tag*: overview
145: *Tag*: done
147: * **Task: Howto: Update the system from binaries**: There is the new tool written in shell named sysupgrade (to be found in pkgsrc/sysutils/sysupgrade), which updates the system in binaries for you. Though it is nice, you may have reasons to not use it for an update (e.g. non-standard systems, or some components may not change).
148: This is why you should document the single tasks sysupgrade does (and why) and fill it with examples, in the end creating an howto which resembles the work done by sysupgrade.
149: [sysupgrade usage](http://www.netbsd.org/docs/guide/en/chap-upgrading.html)
150: *Tag*: howto
151: *Tag*: research
153: * **Task: Howto: Install additional software in NetBSD**: With NetBSD, you have three major ways to install additional software: pkgsrc, pkg_add and pkgin.
154: Which one is to use for which use case, what are their benefits, their merits? Document them, and give a small introduction of the needed tools and their usage (package installation, package deletion, package information).
155: *Tag*: howto
156: *Tag*: system
157: *Tag*: service
159: * **Task: Howto: Dual-boot NetBSD**: Having NetBSD not only as the single operating system, even if only for trying, is a common setup.
160: Of course you can dual-boot NetBSD with its internal bootloader as well as with grub and grub2.
161: These possibilities should be documented, and a howto how to dual-boot NetBSD should be created, for any scenario (NetBSD installed before main OS, and main OS installed before NetBSD).
162: *Tag*: howto
163: *Tag*: research
164: *Tag*: system
166: * **Task: Howto: Encrypt the hard disk with NetBSD**: NetBSD has its very nice cryptographic device driver cgd. Apart from being already described in the [guide](http://netbsd.org/docs/guide/en/chap-cgd.html).
167: An explicit howto how to do this (in short) and how to do this during the installation, is the issue of this task.
168: Though cgd will be in sysinst for the next version of NetBSD, the current ones are still without, so there should be a special emphasis of how to add cgd during system installation.
169: *Tag*: howto
170: *Tag*: system
172: * **Task: Howto: Running usermanagement with LDAP and Kerberos**: Having NetBSD being a server is a common setup. Additionally to all the LDAP and Kerberos setup tutorials in the web, an explicit tutorial how to use NetBSD as an LDAP and Kerberos server would be nice.
173: This means you shouldn't reproduce all the other tutorials about the gory internals, but rather describe what has to be done which is NetBSD-specific (which packages have to be installed, where their configuration files lie, etc.) and just a short chapter about what is needed for the rest, with a reference to the original OpenLDAP and Heimdal/MIT documentation.
174: *Tag*: howto
175: *Tag*: service
176: *Tag*: system
178: * **Task: Howto: Running a webserver with Apache**: As well as the aforementioned task with OpenLDAP and Kerberos, a howto what to do with Apache in NetBSD would be good.
179: This should also include a reference to the already included bozohttpd, which may be suited better in some cases.
180: *Tag*: howto
181: *Tag*: service
182: *Tag*: system
184: * **Task: Howto: Using LVM to manage your disks**: There is already a [chapter about the logical volume manager in NetBSD](http://netbsd.org/docs/guide/en/chap-lvm.html).
185: This task is about not having a whole chapter about it, but rather a small and comprehensive howto how you would manage logical volumes with NetBSD instead of reading through the whole chapter.
186: *Tag*: howto
187: *Tag*: system
189: * **Task: Howto: Protecting your system with veriexec**: There already is [a chapter in the Guide](http://netbsd.org/docs/guide/en/chap-veriexec.html) about veriexec, but there is no comprehensive guide how to activate it and how to check in all files in the distribution (there is [veriexecgen(8)](http://netbsd.gw.com/cgi-bin/man-cgi?veriexecgen++NetBSD-current) for this.
190: Your task is to write a howto describing evrything a user needs to know and needs to do to have a secure system with veriexec.
191: *Tag*: howto
192: *Tag*: system
194: * **Task: Intro: Disk and partition management with NetBSD**: Additionally to the gpt and mbr confusion, NetBSD has two other systems that add complexity to disk management: Disk wedges (dk(4)) and Unix disklabels (disklabel(5)).
195: You should write an article that introduces the reader to these systems, how they interact, and what their use cases are.
196: *Tag*: howto
197: *Tag*: system
199: * **Task: Rewrite system configuration in the guide**: January this year, we got a [new configuration menu for the installer](http://mail-index.netbsd.org/tech-install/2012/01/23/msg000223.html).
200: The chapter in the guide about system configuration is still [the old one](http://netbsd.org/docs/guide/en/chap-exinst.html#exinst-system-configuration).
201: Your task is to rewrite this paragraph, add a new screenshot such that it fits the new configuration menu.
202: *Tag*: howto
203: *Tag*: ui
205: * **Task: Convert articles from the website to wiki articles**: There are several articles on the website (like [this one](http://netbsd.org/docs/misc/index.html)) which should be converted to wiki articles.
206: On the way, you could separate obsolete articles from newer ones.
207: Though this work could also partially be done by a tool like pandoc, the articles on the website have different format: Sometimes docbook, sometimes html, sometimes a mix of them. And pandoc doesn't result in such good results as hand-conversion might do.
208: *Tag*: wiki
210: * **Task: Convert the NetBSD Guide from DocBook to Markdown**: There are already tools to convert docbook to markdown (e.g. pandoc), so they have to be applied. The results have to be checked whether they are useful, and then every chapter should be a single wiki article, with one overview, such that the user optimally doesn't see the difference between the website and the wiki guide.
211: [The guide](http://www.netbsd.org/docs/guide/en/index.html), [the sources](http://cvsweb.netbsd.org/bsdweb.cgi/htdocs/docs/guide/).
212: *Tag*: wiki
214: * **Task: Convert installation notes to markdown**: Currently, the [installation notes](http://ftp.netbsd.org/pub/NetBSD/NetBSD-5.1.2/i386/INSTALL.html) are constructed with mdoc from distrib/notes.
215: The task is to research whether it is possible to convert these articles to markdown, and, if possible, do so.
216: There might be many inclusions etc. to get the original structure, but even the result of *what* has to be done without the actual conversion would be neat.
217: *Tag*: wiki
218: *Tag*: man
220: * **Task: Describe how to run NetBSD headless**: For any server usage, you want to use NetBSD without access to keyboard, mouse or monitor. For these usages, you want to have access via ssh (or something similar, document that) or serial console.
221: Your task is to describe the steps which are necessary to run a NetBSD system headless, i.e. printing boot messages to serial port, enabling the bootloader on serial, enabling the serial port, describing the possible options how to do so, which security measures should be taken.
222: You should also consider systems which don't even have a serial port, i.e. what has to be done if you cannot watch a device start, but you *must* go sure it will come up and you have some sort of access (like a router).
223: *Tag*: howto
224: *Tag*: system
226: * **Task: Describe how to use NetBSD as a bluetooth access point**: With bluetooth, you can easily connect your computer to a mobile phone and let the phone use the network connection of the computer.
227: Your task is to describe how to do this: Connecting NetBSD via bluetooth to your phone and then provide different services (especially file transfer and network connection).
228: *Tag*: howto
229: *Tag*: system
230: *Tag*: network
231: *Tag*: service
233: * **Task: Describe how to use NetBSD as an appliance**: NetBSD is often used for appliances, i.e. a small server serving only one single purpose. Though, there are no howtos describing how to set up a single appliance serving only one cause.
234: Though these howtos are targeted at creating a single appliance, they can also be used for other purposes.
235: Possible appliances would be:
236: * **router** - NetBSD is very well suited for router appliances and often used for that. There is a special task which is about creating a howto how to configure npf and comparing the different firewall solutions NetBSD offers. This task would rather be about everything around, like the routing part, securing the machine, network management (e.g. for wireless access points), and maybe only one example configuration for the firewall (especially NATting). A good example for an existing appliance is pfSense
237: * **file server** - NetBSD is also excellent as a file server, may it be either with nfs, smb, http, ftp or ftp over ssh as the transfer protocol. Your task would be to describe the packages which exist in pkgsrc and in NetBSD's base, and choose one special scenario for each protocol and give example configurations of the services. You should also mention RAIDframe, lvm and cgd briefly and what their use cases are. A good example for an existing appliance is FreeNAS or Apple Time Capsule (already running NetBSD).
238: * **backup server** - though somewhat similar to a file server, a backup server has different requirements. On the one hand, you have to think about how to connect effectively for backups, e.g. with rsync or other special backup protocols. On the other hand, you have to take special care for data integrity and data security. You should also take file system snapshots into account.
240: Every howto for an appliance is considered a single task.
241: As a special task, you could also create a shell script that fulfills the steps you mentioned in your howto, such that the user only has to execute this script to get an appliance. The prerequisite is only for this task.
242: If you can think of more possible appliances, maybe you can also use this as a task. If you want to work on a larger project (i.e. providing a whole derivate with one of these tasks), just tell us.
243: *Prerequisites*: sh
244: *Tag*: howto
245: *Tag*: research
246: *Tag*: service
247: *Tag*: system
248: *Tag*: network
250: * **Task: Describe how to backup NetBSD**: Though NetBSD is much like other Unixes in this respect, backup is still something you should consider specially for every operating system. Which tools are available in the base distribution for backupping, like dump(8) and restore(8)?
251: Which one suits better, pax(1), dump(8) or even just rsync or other special backup solutions? What are their use cases?
252: What is a full, a differential, an incremental backup? What is the estimated space usage of them, depending on the backups?
253: How would you restore your system after a crash, which steps have to be taken to get a working system again?
254: After reading the resulting article, the reader should be able to decide for a backup scheme and solution and implement it without further research.
255: *Tag*: howto
256: *Tag*: system
257: *Tag*: research
259: * **Task: Describe how to create a NetBSD live flash drive**: Flash drives become increasingly the source for operating system installations.
260: Though, you might want to try the operating system first by using a live system.
261: In this task you should create a live USB flash drive from NetBSD. You can use Jibbed or the installation USB flash drive images as an example how to do this.
262: In the end, there should be a howto which steps have to be taken to enable NetBSD to boot from a flash drive.
263: *Tag*: howto
264: *Tag*: research
265: *Tag*: system
267: * **Task: Describe how to become a voip provider**: Sip is a protocol used for VoIP communications.
268: NetBSD was sometimes tried as a VoIP server, but there has been no howto yet how to do this.
269: So, install an Asterisk or FreeSwitch or something else like that and describe how to use NetBSD as a VoIP server.
270: *Tag*: howto
271: *Tag*: service
273: * **Task: Describe what a NetBSD installation does**: NetBSD has an installer called sysinst. But for several cases installations are not run from a system with a direct interface, but rather something else where you don't have sysinst available. Imagine an installation in a chroot environment, an automated installation, with another interface (e.g. ssh), etc.
274: For all these issues, it is necessary to know what a NetBSD installation exactly does. You have to look at the code of sysinst and document what it does in which step, and what is necessary to get a system running.
275: *Prerequisite*: C (reading)
276: *Tag*: howto
277: *Tag*: system
279: * **Task: Describe usage of Multicast DNS in NetBSD**: We have the "Multicast and Unicast DNS daemon" (mdnsd(8)) in NetBSD, which can also be activated directly from the installer (which is one of a few chosen services).
280: To be really able to use it, you have to know what it is and what you can do with it.
281: So, your task is to research what Multicast DNS (or zeroconf) is, and document which of the features is already usable with NetBSD and which ones can be installed via pkgsrc, which ones are completely missing (but relevant).
282: The mdnsd(8) manpage and the Wikipedia page for zeroconf might be a good start for this.
283: *Tag*: howto
284: *Tag*: system
285: *Tag*: service
286: *Tag*: reserach
289: ### Outreach/Research
291: * **Task: Howto: Getting in touch with NetBSD**: If you have a problem, there are several ways to get in touch with NetBSD people: BSD user groups, mailing lists, IRC, problem reports... Which one is the best for which issue?
292: Document the single methods for contacting others and categorize them by the task they're useful for.
293: *Tag*: howto
294: *Tag*: research
295: *Tag*: overview
297: * **Task: Compare init systems with each other**: Additional to the historical ones (SysV and BSD), systemd recently added another init system to the Unix world.
298: An objective comparison of these three systems (if there are other major ones, add them, maybe upstart?) would be nice. Not in the sense of showing their features side-by-side, but simply describing how they work and how you do things yourself.
299: In the end, you should have created a small article that enables anyone using one of these systems to switch to the other one just by reading this article.
300: *Tag*: comparison
301: *Tag*: research
302: *Tag*: system
304: * **Task: Investigate necessary documentation markup**: To choose the right markup language for documentation, you need a clear and comprehensive list of needed markup. While formats like Docbook or Latex support nearly everything, languages like Markdown or RestructuredText are more limited and have different dialects.
305: Your task is to investigate which formats are needed for documentation (links, blockquotes for code, tables, monospace font, headlines in different sizes, etc.) and specify those.
306: Formats like Docbook and mdoc are also providing semantical information, i.e. though they may display everything the same, e.g. the document knows whether a given monospace font written object is a filename, a command name, a function call, etc. Thus you also have to investigate whether these formats are used, and if their usage makes sense.
307: In the end, you should provide a table of needed markup formats and of currently used semantical content of manpages, and whether they are in use somewhere.
308: *Tag*: research
309: *Tag*: overview
311: * **Task: Compare NetBSD with other operating systems of its kind**: NetBSD is an operating system which targets people who like the cleanness of a system, and mostly already have Unix or Linux experience.
312: As such, there are other operating systems which fall into the same audience as NetBSD does, which are at least Slackware, Arch Linux, Gentoo, OpenBSD, FreeBSD, DragonFly.
313: This task is about researching what other distros are out there which are close to NetBSD's principles and use cases (distrowatch.org might be a good starting point), and how they are different.
314: After having collected facts, maybe a simple overview of the community (what kind of people are there, what do they want?), you should create an article which lists all those and describes their differences to NetBSD.
315: You could also try interviewing some people what their view of the communities and the operating systems is and try to evolve your own opinion about them all.
316: *Tag*: comparison
317: *Tag*: research
318: *Tag*: system
319: *Tag*: overview
321: * **Task: Analyze NetBSD's users - research**: NetBSD is a very universal operating system. Some people run it on their 20 years old VAXen, others on their recent desktop computer or server, or on their tiny ARM box as a router.
322: As the aforementioned task (which is rather about the others out there), this task is about doing an in-depth analyzation of NetBSD itself. What kind of users and what kind of developers are out there? Look at the mailing lists, the IRC and the bug reports to get an impression about the community and the developers and what their goals are.
323: This task is also about thinking about some statistical methods you could use. What data is available you could easily analyze, what are the metrics? Do other distributions have the same data available, so you could eventually run these statistics on other operating systems?
324: This task is not about the actual analysis, but only about the methods and measures.
325: In the end, you should create a small paper (about two pages) describing the methods you use, the sources and their reasonation and usefulness.
326: Besides being a gci task, thinking about these statistics, you could also create a nice website analyzing all kinds of distributions based on statistical methods.
327: *Tag*: research
328: *Tag*: comparison
329: *Tag*: overview
331: * **Followup Task: Analyze NetBSD's users - statistics**: This task is about applying the statistics you developed in the task before.
332: You have to write some small tools or scripts that do the analysis you developed before, and then you have to write a two-paged paper about the results, the problems you actually faced when trying to do this task, but no interpretation.
333: If you don't have the computing power or the resources to do the actual analysis, we can help you with that.
334: *Tag*: research
335: *Tag*: comparison
336: *Tag*: overview
338: * **Followup Task: analyze NetBSD's users - interpretation**: Finally, you have to interpret the results you got from before. As you were researching texts which people were writing personally, depending on their mood and ideas, you will be biased by the impressions you got.
339: Now, you have to compare these impressions with your results. What are the right impressions, which are not? What is the overall image you should get from the NetBSD community after doing these tasks?
340: You should write at least two pages of interpretation.
341: *Tag*: research
342: *Tag*: comparison
343: *Tag*: overview
345: * **Task: Analyze NetBSD's focus (in source files) - research**: As the foregoing task, you have to research statistical methods to find places where NetBSD has much effort in. There are already tools and methods to do this, but we want you to actually analyze the semantical focus of NetBSD.
346: What is being most worked on (and in which timescale), comparing kernel to userland, comparing the effort, the lines of code, the frequency of commits, comparing the several subsystems of the kernel, etc. You should also look at bug reports for specific subsystems, and the responsiveness of the people fixing those bugs.
347: You should look at the ports of the NetBSD CVS repository to fossil and git to run your methods locally.
348: You should again write a reasonation about what you differentiate, which methods you use and your results, defending them.
349: *Tag*: research
350: *Tag*: comparison
351: *Tag*: overview
353: * **Followup Task: Analyze NetBSD's focus (in source files) - statistics**: This task is about applying the methods you developed in the task before.
354: You should download the ports of the CVS repository to git or fossil ([see here](ftp://ftp.netbsd.org/NetBSD/misc/repositories/)) and develop scripts to run the analysis.
355: In the end, you should present your results (without interpretation) and defend them in a small two-paged paper.
356: *Tag*: research
357: *Tag*: comparison
358: *Tag*: overview
360: * **Followup Task: Analyze NetBSD's focus (in source files) - interpretation**: Before, you were occupied with developing statistical methods and applying them.
361: But the most important part about statistics is its interpretation - without, everybody will see only the results he likes himself.
362: So you have to interpret the results you got before, comparing them with the overall image NetBSD usually has (see also the statistics task about NetBSD's users) and comparing it with the reality. Where do you see possible improvements, which parts of the source are not cared for enough, which are?
363: Write this down in a paper at least two pages long.
364: *Tag*: research
365: *Tag*: comparison
366: *Tag*: overview
368: * **Task: Analyze NetBSD documentation's focus - research**: This is again a statistical task.
369: You have to investigate methods to analyze the various sources of NetBSD documentation (see the foregoing task, "Create an overview of NetBSD documentation"), and categorize them. Then, you have to measure somehow their content (note that this is not possible by just counting lines or words, as e.g. technical descriptions and tables have much more words in them than rather prosaic documentation).
370: As with the others, you are expected to write a two-paged paper about your used methods and sources, defending their usefulness.
371: *Tag*: research
372: *Tag*: comparison
373: *Tag*: overview
375: * **Followup Task: Analyze NetBSD documentation's focus - statistics**: This task is about applying the methods developed before.
376: You should write scripts to actually do the analysis you proposed before, and afterwards writing down your results in a two-paged paper.
377: *Tag*: research
378: *Tag*: comparison
379: *Tag*: overview
381: * **Followup Task: Analyze NetBSD documentation's focus - interpretation**: In this task, you have to do the final goal of the research before: The interpretation.
382: Based on the results you got before, you should write down your personal interpretation of what you got. You should also mix these results together with the overall impression you got when doing Code-In things, or what you heard about NetBSD at all and what you did with other operating systems.
383: A two-paged paper would be the goal, but if you have more ideas, don't try to fit them into two pages.
384: *Tag*: research
385: *Tag*: comparison
386: *Tag*: overview
388: * **Task: Compare firewall solutions in NetBSD**: NetBSD has several firewall solutions on board: ipf, npf, pf, even more (you should research that).
389: For the beginner, it is not clear what they are capable of, how fast they are and what their syntaxes look like.
390: In this task you should research the differences of these firewalls, create some examples that do the same (so you can view them side-by-side) and provide links to further documentation.
391: *Tag*: comparison
392: *Tag*: network
393: *Tag*: research
395: * **Task: Research terminfo(5) keycodes**: terminfo(5) is a library to describe the capabilities of a terminal.
396: As such, it also has a code for all the special function keys that are on a keyboard. The new terminfo(5) manpage lists all these keys, but not their function. You have to research what the single keys do and insert the description into the list.
397: This bug has also been reported as "lib/47090 - terminfo(5) lacks descriptions for key definitions".
398: *Tag*: research
399: *Tag*: man
401: * **Task: Create lists of software needed for a desktop system**: NetBSD itself is a very puristic operating system. It doesn't deliver much in its base except for the things really needed.
402: As such, it does not provide software you would usually install on your desktop system like a graphical editor, Firefox, etc.
403: In this task, you have to create a list of applications that are needed (only abstract, like "chatting"), and then propose a list of current software used for that and which one you would provide to a user.
404: The goal is to create a list of the applications, and a list of pros and cons of the single packages and why you would recommend them (or not).
405: *Tag*: ui
406: *Tag*: research
407: *Tag*: service
409: * **Task: Survey documentation structure of other projects**: There are many open source projects which exist not only for years, but also for decades (which e.g. NetBSD also nearly does with 19 years). For all of them, documentation is an important issue, and most, if not all projects have not mastered writing documentation.
410: In this task, you have to choose on of the projects listed below. If you want to research another project not listed, please ask a judge about it.
411: Then, you have to research the documentation of these projects (what sources are there, how are they used, which software do they use, which formatting language, etc. (what sources are there, how are they used, which software do they use, which formatting language, etc.), plus finding a way of determining the project's opinion of their documentation (a docs@ mailinglist might be a good start, like e.g. NetBSD-docs@NetBSD.org is). All in all, you should do nearly the same as the task "Create an overview of NetBSD documentation", except that you don't have to be that much in depth, but you should also research the technical and administrational background.
412: In the end, you should write a paper with the results of the survey and a small text, at least one page at all.
413: This task can be fulfilled multiple times, once for each project.
414: *Projects*: Debian, FreeBSD, OpenBSD, DragonFly, Gentoo, Arch Linux, Slackware, PostgreSQL
415: *Tag*: research
416: *Tag*: comparison
417: *Tag*: overview
419: * **Task: Analyze and document (pseudo-)random number generators**: For several purposes like key creation, initial vectors for some protocols, IP sequence numbers, an operating system is required to have a (pseudo) random number generator ((p)rng).
420: Though some are implemented in hardware and the OS gives you the chance to interface them, you most probably just call the function random(3) or open the device /dev/urandom or /dev/random, which is either in hardware or software, depending on what the operating system uses.
421: While the hardware rngs use some random noise as a source for entropy ("randomness"), software rngs use several sources like disk command execution times, network timing, mouse and keyboard usage, depending on the implementation.
422: Your task is to look at the prngs of the great Open Source operating systems, analyze how they work, what input they use, how large their pools are and what exactly is done when input or output occurs.
423: This task is once for each operating system which has a different rng (some operating systems share the same ones), but you should analyze the input sources for all OSes using that rng and do the analysis for NetBSD first.
424: You should write down your result in a paper at least two pages long.
425: While this task might take up more work than a usual task, it is a very interesting and demanding task especially if you are interested in mathematics or cryptography.
426: *Tag*: research
427: *Tag*: comparison
430: ### Quality Assurance
432: * **Task: Document integrated tools in NetBSD**: Apart from the famous web server and ftp server choices, there are smaller ones already integrated to NetBSD, as well as other smaller tools a user should know.
433: The goal is to create a comprehensive (!) list of full software packages that are already included in the base distribution.
434: In the document src/doc/3RDPARTY there is already a list of imported software, but there are more tools which are NetBSD-inherent themselves or contained in a larger package that is just listed as a whole there.
435: *Tag*: overview
436: *Tag*: research
438: * **Task: Try out various desktop scenarios, report errors**: Modern desktop environments like Xfce, KDE, Gnome or LXDE are mostly written for Linux. As such, it is important to try them on NetBSD and report their errors. Plus, checking the ease of installation via pkgsrc - which packages have to be installed, how intuitive is their name, their installation? Everything should be as easy as possible.
439: This task also refers to the task of creating a tutorial - maybe doing this first, and then creating the tutorial would be nice. The tutorial could either be updated on the fly when the reported bugs are corrected, or will be held back until the process is as easy as it should be.
440: This also includes bug-checking for light-deskop, the preferred package for a NetBSD desktop.
441: *Tag*: ui
442: *Tag*: research
444: * **Task: Document the installation of the DeforaOS desktop environment**: The DeforaOS desktop is an alternative for a lightweight desktop environment, and is already packaged in NetBSD (via pkgsrc-wip, as the wip/deforaos-desktop meta package). It could use more documentation though, including how to configure it properly.
445: Bug reports will also be welcome of course, even more so with fixes.
446: *Tag*: ui
447: *Tag*: research
449: * **Task: Make NetBSD a music or video player**: NetBSD could as well serve as a music (mpd) or video player. You have to research which packages are needed for such a use case, and document it in a tutorial.
450: Ideally, create a pkgsrc meta package including all the dependencies.
451: Report bugs you find on the way.
452: *Tag*: ui
453: *Tag*: research
456: * **Task: Describe how NetBSD boots**: Build NetBSD on any system (especially non-NetBSD) and try to create a bootable medium without using makefs(8) or integrated wrappers.
457: Creating a bootable disk is possible, but difficult and there is no comprehensive information about this. You have to try much until you get the real results.
458: The affected tools are
459: * fdisk(8)
460: * installboot(8)
461: * disklabel(8)
462: * gpt(8)
464: In the end of this task, a small howto and some corrections for the manpages of the affected tools should be there.
465: *Tag*: system
466: *Tag*: howto
468: * **Task: Describe how to boot NetBSD on a gpt disk**: Currently, NetBSD supports booting from a gpt partition, but you cannot know how.
469: This task is about creating documentation how to use the tool gpt(8) and maybe installboot(8) how to create GPT labels, how they interact with MBRs as created by fdisk(8), how wedges work on this, and how you would make it bootable.
470: You should also describe which problems you have and what people might edge on when trying to create a gpt-bootable disk.
471: *Tag*: howto
472: *Tag*: system
474: * **Task: Howto: Configure npf**: The new NetBSD packet filter npf is a nice and well-scaling way to configure a firewall. Despite being there and functional, it does not have much documentation.
475: The manpage of npf.conf(5) gives an introduction, but nothing that could be used as a howto: [npf.conf(5)](http://netbsd.gw.com/cgi-bin/man-cgi?npf.conf+5+NetBSD-current).
476: The howto should contain a step-by-step introduction about how npf works, but also an introduction to the technics of npf itself: What kind of rules and tables are there, how they are applied, etc.
477: There is already a [howto by rmind](http://www.netbsd.org/~rmind/pub/npf_manual_netbsd_6.pdf), this would have to be converted and checked against errors, and extended.
478: *Tag*: howto
479: *Tag*: network
481: * **Task: Using the framebuffer in NetBSD**: NetBSD has a framebuffer, but until now, it is not much used. The framebuffer can be used for showing nice fonts and resolutions in the console, to show a spashscreen while booting, etc., but there is no documentation.
482: The genfb(4) and wsdisplay(4) manpages are a good start with this.
483: Your task is to try using the framebuffer, document what you are doing and why, and report what is missing and where you have no idea how to go on.
484: *Tag*: ui
485: *Tag*: system
487: * **Task: Research and write a Markdown style guide**: NetBSD is using Markdown for its wiki. To have a unified format of wiki pages, it would be nice if we had a style guide.
488: Your task is to research whether other projects which are using Markdown have a style guide, and what it implies. You should also research the other style guides of NetBSD (for the website and for source), and then deduce a style guide for the NetBSD wiki for this.
489: *Tag*: research
490: *Tag*: ui
492: * **Task: Research POSIX compliance**: POSIX is the (more or less) standard all Unixes orient on. It describes libraries to use as well as binaries every Unix should have (like cp, mv) and their behaviour.
493: You can find the standard on the Internet. Your task is to look for any non-trivial manpage (i.e., more than a few options) and research whether the NetBSD behaviour of this tool or library conforms to POSIX or not.
494: You should then insert this part into a list and document whether it complies to POSIX and if not, which differences are there.
495: As it is hard to determine the difficulty of a single part of the standard, this will be measured in lines. For every 1000 lines of the NetBSD versions of the manpages, this is one task.
496: The prerequisite is only for looking at libraries.
497: *Prerequisite*: C (reading)
498: *Tag*: research
500: * **Task: Measure startup time**: NetBSD doesn't have many services enabled by default, though most people add some more services they need for a system (depending on the usage).
501: Your task is about researching some of the most used services and the daemons that are inside NetBSD already, and measure the startup time depending on which and how many services are enabled.
502: You should write your results either in tabular form or in a paper at least two pages long, then also concluding your results.
503: *Tag*: system
504: *Tag*: service
506: * **Task: Try out VoIP software**: There is much VoIP (i.e. SIP or Jingle/XMPP) software in pkgsrc, but which one works best vor NetBSD, which one provides the best features?
507: Create a comprehensive list of those, and report what does and what does not work with them.
508: *Tag*: service
509: *Tag*: ui
511: * **Task: Try out XMPP software**: XMPP is a protocol for exchanging XML structures. Mostly it is used for the well-known chat protocol Jabber (like e.g. Google Talk and Facebook use).
512: There is much software providing XMPP access. You should research all those, look which ones are already in pkgsrc, which ones should be.
513: Then, you should install them and try them out and document if something is not working.
514: *Tag*: service
515: *Tag*: ui
518: ### Code
520: * **Task: Create ATF tests**: [[atf]] is the automatic test framework for NetBSD. We strive to have automatic tests for all the important parts of our system: libraries, syscalls, binaries, etc.
521: Your task is to write such tests. You should read the [[tutorial|atf]] about how to write an atf test, and then you can start testing things.
522: As testing is an endless task, here are just a few ideas about which items could be tested:
523: * [[!template id=man name="atomic_ops" section="3"]]
524: * [[!template id=man name="cdbr" section="3"]] and [[!template id=man name="cdbw" section="3"]]
525: * [[!template id=man name="inet" section="3"]] and [[!template id=man name="inet_net" section="3"]]
526: * [[!template id=man name="ethers" section="3"]], [[!template id=man name="iso_addr" section="3"]] and [[!template id=man name="link_addr" section="3"]]
527: * [[!template id=man name="strtol" section="3"]], [[!template id=man name="strtoul" section="3"]] and [[!template id=man name="strtoull" section="3"]]
528: * [[!template id=man name="uuid" section="3"]]
530: Though this task is originally rather considered quality assurance, the actual test writing is only coding work (whether the test succeeds or not, is up to the original author of the library or tool).
531: Every *single written test* is considered as **one task**. If you think there is another test that should be added, but is not listed here, feel free to contact us.
532: The tests should be written in either C or sh, depending on the test subject.
533: *Prerequisites*: sh or C
534: *Tag*: man
535: *Tag*: research
537: * **Task: Document different time structures**: We have several time structures like `time_t`, `struct timespec`, `struct timeval`, `struct tm` and so on. Document all of them as a time(5) manpage such that a programmer can see all of them at once, in comparison. As we have time zone sensitive and time zone independent representations, figuring out conversions between local time and UTC from manual pages is hard and should also be documented in that manpage.
538: *Prerequisites*: C (just reading)
539: *Tag*: man
540: *Tag*: system
542: * **Task: Add an web interface to apropos**: Last year's Google Summer Of Code project was creating a new apropos(1). Though the current version already has a web interface, adding CSS and appropriate HTML to the web interface would be nice to integrate it to other websites.
543: Though the source code is written in C, C knowledge is not necessary. You just have to extract the HTML and pseudo-understand what the code around it does, i.e. in which cases the single actions are taken.
544: The file which would be modified is [apropos-utils.c](https://github.com/abhinav-upadhyay/apropos_replacement/tree/cgi).
545: *Prerequisites*: C CSS HTML
546: *Tag*: ui
547: *Tag*: graphics
549: * **Task: Write apropos branch to search through Markdown documentation**: apropos(1) is a last summer's Google Summer Of Code project implemented in NetBSD. It allows a relevance-based search through manpages written in mdoc.
550: As maybe Markdown is going to be in the source tree, we want to extend apropos to also be able to search through generic documentation articles.
551: Your task would be to research the possibility of creating another binary that is able to search through markdown documentation pages, creating its own index file (mandb).
552: If you are having fun with this, thinking about ways how to combine the two binaries into one single documentation search binary would be good.
553: [Mail announcint import of apropos](http://mail-index.netbsd.org/tech-userlevel/2012/02/01/msg006040.html)
554: *Prerequisites*: C
555: *Tag*: research
556: *Tag*: man
558: * **Task: Write a Markdown - Latex converter**: This task is not strictly for NetBSD, but another project named [libsoldout](http://fossil.instinctive.eu/libsoldout). libsoldout is a markdown converter written in C and published under public domain.
559: Though there are already other tools which would do this task, they either have a licence that is not usable by NetBSD or have too many dependencies (like pandoc).
560: Your task is to write a converter from Markdown to Latex (or PDF, which might be a fairly large task and not suited for Code-In), which is just specifying some tags you use for inserting and putting it in C code.
561: You can take the [html](http://fossil.instinctive.eu/libsoldout/artifact/fd100c723c722189d62fd9bf261d67db69240043) or the [mdoc](http://fossil.instinctive.eu/libsoldout/artifact/1e22b7962dfba92c28f4916609746045dbe29a90) converter as a template for this. Though this task seems large, the task itself is rather small. You have to analyze the converters for mdoc and html and replace their tags by the appropriate Latex ones.
562: If you're not as good with Latex, feel free to ask for the tags that are to replace. Latex is not a strict prerequisite!
563: *Prerequisites*: C Latex
564: *Tag*: research
565: *Tag*: wiki
566: *Tag*: ui
568: * **Followup task: Create NetBSD slide templates (Latex)**: Many people are used to using the [Latex typesetting system](http://de.wikipedia.org/wiki/Latex) beamer package for presentations instead of OpenOffice.
569: Thus, you should convert the OpenOffice template created in the according User Interface task to a Latex template.
570: This task is also a great chance to get used to the Latex package beamer or to Latex at all, it is usable for any presentations in school or university. So don't hesitate if you don't fulfill the prerequisite, if you want to learn, you can relatively fast do it and then complete this task.
571: *Prerequisite*: Latex
572: *Tag*: graphics
574: * **Task: Fix bug install/17792**: The problem in this bug report is clear: The function get_and_unpack_sets() in util.c calls the menu MENU_distmedium as long as the status is set to retry.
575: The solution is to run this menu once before actually getting into this loop, before actually writing the changes to disk (see the file install.c or upgrade.c for an example).
576: Though the user who is used to fetch its sources from more than one source will be confused about the changed order of the question, 99% of the people won't even notice it.
577: *Prerequisite*: C
578: *Tag*: system
580: * **Task: Fix bug bin/46579**: The problem in this bug report is already analyzed: There is a general dispatcher for the requested tasks of ifconfig. After fulfilling these tasks, ifconfig goes on to show information, but then, the interface doesn't exist anymore.
581: You have to think of a clean way how to circumvent this, i.e. either catch non-existing devices before the task of ifconfig is done, or do a differentiation afterwards such that the error is not printed anymore.
582: ifconfig is a very complex tool, so expect a high difficulty from this task, not in the coding part, but in the analyzation part!
583: *Prerequisite*: C
584: *Tag*: system
586: * **Task: Repair vnconfig(8)'s return codes**: vnconfig(8) is a tool to create virtual disk images. There was a (not officially filed) bug report that it sometimes returns success although it fails:
587: > qemu# vnconfig vnd0 not_existent_file ; echo $? ; : bad
588: > vnconfig: not_existent_file: No such file or directory
589: > 0
590: > qemu# vnconfig vnd0 existent_file ; echo $? ;: good
591: > 0
592: > qemu#
593: In this task, you will go through the whole work of fixing a bug: You have to analyze the situation, find the source of that bug in the code, and finally fix it.
594: *Prerequisite*: C
595: *Tag*: system
597: * **Task: Fix bug bin/47089**: Apparently, the well-known tool mv(1) (for moving files around in the file system) does not return an appropriate error message when you try to move a mount point of a file system.
598: In this task, you will go through the whole work of fixing a bug: You have to analyze the situation, find the source of that bug in the code, and finally fix it.
599: *Prerequisite*: C
600: *Tag*: system
602: * **Task: Fix bug bin/47065**: The shell returns a wrong error code when it should return an error (on a bad file descriptor).
603: In this task, you will go through the whole work of fixing a bug: You have to analyze the situation, find the source of that bug in the code, and finally fix it.
604: In this task, you will also learn much about how a shell internally works. This will help you definetely if you want to do shell programming some day, or just want to dig more into the internals of file descriptors.
605: *Prerequisite*: C
606: *Tag*: system
608: * **Task: Fix bug bin/41049**: The description of "usermod -g" in the manpage does not accord to its real behaviour. Actually, this has not been implemented, so you have the rather difficult task to write the implementation for this.
609: You can use code from the other tools which deal with user and group modification, maybe you will find a place where nearly the same work has already been done.
610: *Prerequisite*: C
611: *Tag*: system
613: * **Task: Write a mail wrapper**: NetBSD, as almost all Unixes, brings a mailserver (Postfix) along with its standard system.
614: This mailserver is enabled by default to let outgoing mails through, but most mailservers won't accept mails from dial-up networks. So the most common way is to use another mailserver with your common mail account to relay mails.
615: Your task is to write a small wrapper that does the authentication needed for most SMTP relays, such that a user only has to insert his account details for e.g. Gmail and then can relay the system mails there.
616: You should also take into account relaying the system user's mails to that account or document how you would do so. This would entail (though this is not part of this task) having a configuration for several users, such that they can setup this for themselves without others seeing their password.
617: This task doesn't have to be necessarily code, a comprehensive guide on how to do this by hand would also be sufficient (but not obsoleting the coding task).
618: *Prerequisite*: sh SMTP
619: *Tag*: system
620: *Tag*: network
621: *Tag*: service
622: *Tag*: howto
625: ### User Interface
627: * **Task: Create a concept for a documentation browser**: There are many possibilities to ship documentation together with the distribution. Most operating systems stick to providing their documentation PDF, HTML, cleartext, GNU info or manpages. NetBSD currently uses various formats for documentation, but for this task, this doesn't matter.
628: In case your system is offline (when the Internet connection shut down, or you are on your notebook), you want to have this information available.
629: We want to write an offline documentation browser, but the whole user interface is unclear. What kind of links do you provide (remember: A browser might not be available)? How do you select them? By numbering them, by commandline (like vi), by selecting them with cursors? When using cursors, how do you browse? How would you implement a browser history?
630: This task is not strictly user interface, you also have to research how it is possible. We want to reuse as many tools as possible (like less(1)) as they sometimes fulfill complicated tasks.
631: In the end, we expect a declaration of how the user interface should look like, such that the programmer can directly start to program this interface. You should not only provide this declaration, but also a reasoning why this choice is the best one, and some conceptual drawings that show your interface "in action".
632: If this task is interesting for you, we can support you also after Code-In if you want to write such a browser (in C), the actual language for the markup depending on a prior task.
633: *Tag*: research
634: *Tag*: wiki
636: * **Task: Create NetBSD wallpapers**: Currently, there are nearly no NetBSD wallpapers. The combination of beastie, the flag and the old logo (daemons on old computers), plus the very smooth NetBSD colours (orange, grey, white) should be a resource for nice wallpapers.
637: If you're fine with drawing on a computer or graphical programs (like The Gimp or Photoshop), this might be a nice and very creative task for you.
638: *Tag*: graphics
640: * **Task: Create an icon set for NetBSD - research**: To provide a nice graphical user interface, as well as prettifying the wiki and the website, having some buttons and icons would be nice.
641: This task is about gathering and writing down what sizes are useful, and what kinds of icons are needed (and what they could be used for).
642: For this, you have to research what icons a current desktop environment uses (there are icons in /usr/pkg/share/icons) and then specify what motives are useful. You do not have to say there should be an icon for "file browser", but an icon for "a cupboard holding folders". The icons should stay generic.
643: *Tag*: research
644: *Tag*: ui
646: * **Followup Task: Create an icon set for NetBSD - graphics**: In addition to the previous task, creating those icons is still needed. You would have to think about an artwork concept which loosely orients on the NetBSD corporate colours (orange, grey, white), maybe even providing two colour sets (additionally orange, grey, black), how these icons should look overall and creating the single icons that are specified.
647: The icons should be in a vector graphics format like as Inkscape creates, such that in the future, we can choose to produce hihgher resolution icons.
648: As the whole icon set would clearly be too much work, this task is about creating **three icons of your choice** that have not yet been created, thus this task can be fulfilled multiple times.
649: *Tag*: graphics
650: *Tag*: ui
652: * **Task: Create smaller NetBSD artwork**: NetBSD does not have much artwork. Except from the aforementioned wallpapers and icons sets, multiple smaller artworks would be nice as well.
653: This includes drawing comics, creating a CD label, the image of a flash drive with NetBSD on it or e.g. a Beastie with a NetBSD flash drive, such things.
654: If you want to do this task, even if you don't know what to do, just contact us. We can tell you some ideas what to do, and if you already have one, approve it is suited for us.
655: *Tag*: graphics
657: * **Task: Create NetBSD slide templates (OpenOffice)**: NetBSD developers often hold presentations on conferences like the EuroBSDCon, BSDCan, etc.
658: Your task is to think of a non-intrusive design which still reminds people of NetBSD, but without focussing on that. After that, you create a template that can be downloaded, included and then simply used such that NetBSD presentations have a NetBSD branding.
659: *Tag*: graphics
661: * **Task: Create a NetBSD book layout**: NetBSD has several articles that could and are converted to PDF. While the final conversion and its methods is another task, having a nice book layout is necessary.
662: In this task, you have to research the different styles a NetBSD article would need (i.e., code blocks, other blockquotes, special quotes for commands, for manpages, etc.) and everything around like a front page, the font, etc.
663: You can deliver the specification either as a Latex style or exactly written with some example images.
664: *Tag*: graphics
666: * **Task: Create a NetBSD poster**: NetBSD advocacy material is used on fairs where NetBSD usually has its own booth. To make the presentation more attractive, a nice poster (in format A0) would be nice.
667: This task can be fulfilled multiple times. You can either create different posters advocating different aspects of NetBSD, or just create graphical posters.
668: *Tag*: graphics
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb