User talk:Rahayupuji333

Essay Writing
Meeting 1

Wiki Practice

Collaborative Wiki Writing This page contains guidelines and tips on how to write a document collaboratively in Trac. We suggest two methods to signal revisions suggestions (and other comments) in a wiki page: 1.	For smaller revisions, in particular suggestions for wordings, use text editing features. 2.	For larger revisions, in particular those that involve corrections/modifications on the idea level and/or searching for new information and/or elaborations beyond paraphrasing, use tickets. Tickets should also be used when the reviewer or editor suggest re-organisations of the text, i.e. moving parts around. Text editing for small revisions A typical problem when writing together is how to indicate clearly what is meant as a comment on existing text, as different from new text. We need to be able to distinguish the two. Here are three possible ways to do so: __underlined text__ yields: underlined text Example: Magnus es, domine, et laudabilis valde: magna virtus tua, et sapientiae tuae non est numerus. et laudare te vult homo, aliqua portio creaturae tuae, et homo circumferens mortalitem suam, circumferens testimonium peccati sui et testimonium, quia superbis resistis: I would say instead: dobido /pr/ laudare te, et scire te prius sit an invocare te. sed quis te invocat nesciens te? aliud enim pro alio potest invocare nesciens. ticket:10 Preformatted Text ¶ Block containing preformatted text are suitable for notes and examples. Use three curly braces wrapped around the text to define a block quote. The curly braces need to be on a separate line. Example: Display: everthing will be shown exactly as typed and with a box around it. Another Example: Magnus es, domine, et laudabilis valde: magna virtus tua, et sapientiae tuae non est numerus. et laudare te vult homo, aliqua portio creaturae tuae, et homo circumferens mortalitem suam, circumferens testimonium peccati sui et testimonium, quia superbis resistis: Here is some new information you may find helpful for this paragraph et tamen laudare te vult homo, aliqua portio creaturae tuae.tu excitas, ut laudare te delectet, quia fecisti nos ad te et inquietum est cor nostrum, donec requiescat in te. Discussion Citations ¶ To delineate a citation in an ongoing discussion thread, such as the ticket comment area, e-mail-like citation marks (">", ">>", etc.) may be used. Example: >> Someone's original text > Someone else's reply text My reply text Display: Someone's original text Someone else's reply text My reply text Recommendations for Reviewing: Use underlining for inline comments, and discussion citations for comments on paragraphs. It is also highly recommended to leave your name on longer revisions or on comments you expect writer(s) to want to react to. (Strictly speaking, mentioning your name in the text is not necessary because TRAC keeps track of all authors and changes, but you would need to use the versioning features (see below) to find out.) Versioning and Commenting ¶ Each wiki page has its history stored. That can be accessed via the Last Change link on the very right of the wiki page top line. When the last change is displayed, you have access to the complete page history via the Page History link. The page history is particularly informative when used in combination with commenting changes. The Comment about this change field at the bottom of the wiki page (visible in editing mode only) allows to enter a description of the changes performed in the current edit. It is highly recommended to comment changes (these comments also appear in the Time Line), in particular those that affect the meaning of the text (i.e. other than spelling and layout changes). It is also a good idea to indicate what type of change has been made in the edit when commenting a change. For writing tasks, these are good categories: •	New text •	New text (copy and paste) •	Question raised •	Question answered •	Revision raised|accepted|rejected -- see, alternatively, tickets below •	Rearrangement •	Deletion Video Tutorial: Here is a video as windows avi and in quicktime format on this topic. Tickets for large, critical revisions ¶ So far, we looked at means for adding "meta" information to text using just the wiki. In order to manage more complex actions around documents, you want to use TracTickets. They are a bit more complex, but a powerful tool once understood. Example: et scire te prius sit an invocare te. sed quis te invocat nesciens te? aliud enim pro alio potest invocare nesciens. an potius invocaris, ut sciaris? quomodo autem invocabunt, in quem non crediderunt? aut quomodo credent sine praedicante? et laudabunt dominum qui requirunt eum. ticket:7 Magnus es, domine, et laudabilis valde: magna virtus tua, et sapientiae tuae non est numerus. Tip: right-click on ticket links, and open the ticket in a new browser window. That way, you see the text and the revision note side by side. Video: We prepared a screen cast (with voice over) on the basics of ticket use in quicktime and mp4 (itunes etc.) format. In order to use tickets for manage writing and revision tasks, we need to establish a couple of conventions. Creating a ticket ¶ You can create a ticket using the New Ticket button in the menu row at the top. Type a title for the ticket, and select an appropriate task type, one of: •	searchTask -- to find new/additional information: Use this when too little is known yet on x to write on x, or more needs to be known to write more/better. •	writingTask -- new text to write •	revisionTask -- revision suggestion raised If you want to assign a ticket to a specific person, use the Assign To: field. Use the username from the drop down box for this. Reviewers will typically assign a ticket initially to the editor of the document, not any of the writers. (A bit of trac terminology: the reporter is the one who creates a ticket (which means, in general, that the reporter found a flaw in the artefact created); the ticket owner is the person who accepted the ticket, and by this indicated that he/she will work on fixing the flaw. The owner will be informed by email notification of any changes in tickets he/she owns.) Use the Version field to select your team. This way, tickets can be kept separate for teams. Managing ticket state ¶ Typically, editors would issue search, writing and revision tickets after Monday evening sessions in accordance with team decisions. Writers and reviewers would check their tickets, accept them, and work on them as well as their general tasks for the week.When done, they would close the specific tickets (set state to "fixed"). Reviewers would create revision tickets in their review sections for revisions that involve somewhat substantial changes and/or searching for new information. Reviewers would not necessarily assign owners, though, before the editor decides if the revision item requires action - and by whom. The default owner for a revision decision is the editor, not the writer. Editors would decide on revision tickets (at times seeking advise from the whole team), and on who the revision will perform (by default it would be the writer of the section). In general: Editors: •	create search and writing tickets; •	decide which revision tickets will be worked on, and by whom (which writer becomes the owner of a revision ticket). Reviewers: •	accept tickets assigned to them; •	create revision tickets (with name of editor as owner). Writers: •	accept tickets assigned to them; •	close writing and revision tickets assigned to them. All team members: •	accept tickets assigned to them; •	close search and other tickets assigned to them. Finding tickets assigned to team members ¶ The most important searches on tickets are readily accessed via button View Tickets: •	Tickets assigned to you ('me'): http://trac.edfac.usyd.edu.au/EDPC5021_2009/report/7 •	All open tickets by team: http://trac.edfac.usyd.edu.au/EDPC5021_2009/report/2 •	etc. The review process conducted with tickets ¶ The review process conducted with tickets means to raise tickets to the editor... ... and the editor (with and/or without the team) deciding on revisions (re-assigning ownership to writers or setting ticket status to fixed): The editor can conduct a decision process in the Monday meeting (synchonously) and/or by email and/or as a discussion in the ticket under question. You should not use email, if possible, but if you do, the mail exchange(s) needs to be documented in the ticket (copy&paste). When using tickets, we "lift" the reviewing process for an issue out of the document (wiki page), perform the decision making process on the issue in the ticket (this may include discussions), and only after a decision has been made return to changes in the document (wiki page). We use the TRAC feature that tickets keep a 'local' history of all changes on the ticket, and that you can comment and discuss all changes in a ticket before performing the definitive edit in the document (wiki page). See the change history of ticket:7 for an illustration of a discussion in a ticket comment field.