Author: wagner.sa

Looking over the schema template the only real change that it appears was made was the addition of “legal” and “other” subelement options beneath the feasibility heading. I think that adding these two categories is hugely helpful, especially with the addition of other. This allows for the author to add more information that may be project specific and not fall under any of the predefined subelements. Although this is not something that our team had initially discussed it adds additional room for proposal flexibility which was very important to us when writing the schema.

Other issues discussed in the team design post by the second group for the public initiative proposal included the addition of a global reference element and changes to the definitions and requirements for some of the attributes. Although the team did not suggest any possible definition alternatives it was definitely something that our original team had discussed and struggled with finalizing. Because each team member was looking at the genre from a slightly different angle based on our majors and experiences we tried to keep definitions and attribute requirements as general as possible while still providing sound guidance in structure. It was important to us that the document be able to reflect the project that it was for in a very specific and fitting manner contextually. The addition of a global reference element was something that we had talked about as well, however we were told that it would be a bit difficult to incorporate and because this genre was focused at the public we figured it was slightly less academic in nature and that in text reference call outs would not be necessary as long as those references were listed in a works cited at the end of the document. Overall I would say that I understand where all of these comments and changes are coming from and I agree that they would make a good addition and fit with the general goal that team 3 originally had for the schema.

Initially when I was working on my first draft for writing project 3 I was writing directly into the XML document replacing team fours example texts with my own words. However, in doing that my statements felt disconnected and scripted. For this reason I ultimately ended up writing the majority of my intro and background paragraphs in word and then transferring it back over into XML. It was nice to have the example texts in the schema template to understand what they meant by each of the tags. I found it more useful though to use the teams presentation as a starting point for the context of my letter. I did find the schema’s overall layout to be broad enough to cover any possible rhetorical situation that would lead to the writing of a cover letter. Being able to order your background in different ways while still prompting you to include personal, academic and work related experience was quite helpful given the fact that my situation may have been slightly different than that of other people writing a cover letter. It would have been nice to be able to use the reasons tag multiple times within the background sections, but it worked out regardless by just grouping it.

Receiving my peer review was tremendously helpful as I think it gave me an idea not only of how to fix the things that I asked about but also because he pointed out things that were missing or unclear that I had not previously noticed. Overall I think that the schema was very straightforward with the example text that was included. I do think that some of the tags within elements could have been better defined, but generally plenty of labels to be sure that you included all the necessary elements.

Using another groups schema was fairly straightforward though it did not have the benefit of already knowing examples and how the schema breakdown matched those examples. Potential things to change:

• being able to include multiple reasons for things
• unsure of the purpose of the page break element when everything is already so broken up
• being able to include a space under your salutation before your typed out name to allow room for a signature
• a place for a date at the top of the document somewhere

For this project, unlike with project one, I used the schema as a direct input for each draft of my writing. I filled each contextual section in with information piece by piece and then chose to read back over the piece as a whole to make sure that the document made sense as a whole as well. I felt that the schema that my group wrote together was a great representation of a very basic and overly generalized proposal. We left each of the sections broad enough in description that people could chose to take it wherever they wanted while still maintaining a logical flow. For my particular project I did not feel that this was quite as helpful as it could have been. Because there was a lot of disagreement certain sections were left out of the schema overall rather than making them possible optional sections which I would have liked to use. However, the format of our schema template was very straightforward and easy to use. The reading for me that I think helped the most with our genre analysis was the Spinuzzi article on ways to examine different assemblages of text. Being able to group different view points on genre situations was helpful because it helped me to fully grasp the complexity of the genre we were working in. Working with the group to create the schema and bring examples together for analysis was hugely beneficial. However, when writing the team design entry we had a difficult time making sure that all of our ideas were included and that the sections flowed together nicely. For this reason I think that maybe writing those individually and simply discussing them would have been more helpful. Overall I felt that this project was very manageable and was a useful topic to learn. The only thing I would change is maybe having a simpler explanation of each of the milestones that we were scheduled to meet prior to the start of the project. There were some times that I was just focused on the current step cause I wasn’t sure exactly what was coming next and having that more holistic understanding might have helped to get a better grasp on the project earlier on rather than just at the end. 

The genre that most interests me is group 4’s cover letter analysis. I think that this genre would be an incredibly useful one to study now considering we will all be applying within the next few months to either new co-ops, summer internships, or future full time jobs for after we graduate. I personally, am in the process of applying for my dream summer internship and have been asked to provide a very open ended cover letter stating my interests and company specific goals. For this reason, I think that doing a cover letter for my third writing project would be very helpful for myself to get started on the letter and be able to analyze deeper different styles or types of information that may be included in a good one.

Cover letters are a commonly requested item when job openings are posted by companies. The audience would be all those people looking for that type of job. The desired uptake would be that the author would receive an interview opportunity to further discuss the job and their qualifications. The schema/template file is very concise yet covers all of the possible subjects that your cover letter should touch on. The files are written in a very professional manner and have a predetermined structure. Additional research on my behalf would mostly involve looking into the differences between letters for internships as opposed to full time positions if there is any as well as research into a company of interest to properly enter the desired situation.

When writing my initial draft for writing project 2 I used the schema as an initial outline to be filled in piece by piece with relevant information. For project 1 I had written the entire project out in a word processor initially and then broken down the pieces to be put back into the schema for an annotated bibliography. However, this time around I decided to try writing my proposal document in pieces based on the schema and then read back over it to correct for any repetitiveness or inconsistency. The schema we have created fits well with my rhetorical situation however, at times its format is a bit too rigid for the types of information that I am trying to display. I would not say that the schema constrained the context of the proposal. If any thing it probably helped to keep the report formal and logical in its ordering of information.

The piece that I peer reviewed was much different from my document. It was straightforward in its approach and kept the information in each section concise and to the point. The project proposed in it was made slightly simpler than it would be in real life in order to keep within the constraints of the assignment. Because of this I feel like there are a few areas where problems or opposition could be discussed more further or that his project could be a little bit more thought out as far as a long term solution.

Using the schema created by the class as a whole in project one was a bit easier because we had talked about each aspect so in depth that it felt like the elements had become very general and were well understood by everyone using it. In this project thought, the schema felt slightly constrained due to the fact that it was made by fewer people looking at a larger variety of examples. By trying to keep each element broad but still descriptive there were definitely areas that became a bit specific to certain types of projects or proposals.

Generally there is usually a document called a request for proposals (RFP) which is submitted by a town or organization calling upon members of the community to provide proposals outlining their ideas or proposed plans to solve a “problem” or to enact an idea put forth by the town. At this point project proposals are written and submitted to a board of town members who were appointed to the project. Following a proposal comes a series of meetings, whether that be with the town or only with the board members who then decide which proposal they are going to enact or fund. Although previous genres are not directly represented in our schema we did take into account the information that would be given to people in an RFP for them to be able to iterate back in the proposal. The objectives and the goals sections allow for the writer to address the requirements of the RFP in an obvious and straightforward way.

The direct uptake of our genre is discussion. Because there is rarely just one proposal submitted your ideal uptake would be that post discussion the town or the board decides to go with your project but that is not always the outcome. If they do pick your project you may be issued a project budget or asked to submit a more detailed plan or schedule. This desired uptake is represented in our schema with the plan section of the proposal which would outline initial schedules and budgeting plans.

The biggest way that uptake influenced our genre model is that it is primarily a basis for discussion. A proposal has to be broken down into simple and easy to follow steps that all sorts of people can understand and get behind. With most technical writing it is very important to know your audience so that you can give them the most information possible without overwhelming them or losing them along the way. In most cases though you are typically communicating with fellow engineers or project managers. In the case of public initiative project proposals however you are writing for doctors, stay home moms, bankers and people who may not necessarily have the technical know-how that your discipline relies on to support their ideas.

For writing project two, my team is focusing in on project proposals. More specifically public initiative proposals for projects that aim to improve a community by presenting a laid out plan detailing the problem at hand, possible solution and ways to achieve the solution. A number of different forms of both official and unofficial texts revolve around the planning, writing, and presenting of a project proposal.

Prior to receiving any sort of proposals, a city usually has to publish a public RFP (request for proposals) to inform the community of an opportunity to develop the city in some way whether that be to form a youth basketball league, rebuild the town library, or instal a new public art exhibit in the park or public areas. Prior to the RFP, towns usually hold a meeting or forum to discuss the possibility of implementing this new project and to gather ideas and opinions on specific details that the project should achieve. This information collected at the meeting will be the information that is processed and simplified down into a set of requirements to be published in the RFP. Because the project and proposals will all affect the community as a whole, much of the information being distributed on each level will be made public for people to read and ask questions about and are therefore meant for wider consumption by anyone who is interested. No part of this proposal process is internal to any particular organization. There may be associated internal communications within the companies or groups creating proposals to be submitted, but their final proposal is meant to be submitted to the city (or a group working on behalf of the community) to become public record.

Genre repertoires seem like a very interesting perspective to take when researching the proposal production process. It is definitely meant to be communicative in an official setting. However a lot of the process that surrounds the proposal process is both sequential in its official format, but unofficially there is a lot of overlap between the different genres associated with them.

Chris Murphy’s annotated bibliography focuses on the issue of sustainability. His research focuses in more specifically on the use of electric vehicles instead of combustion engines for public transportation and waste removal. In the problem statement Chris addresses the larger effect that these two types of vehicles already have on the environment as well as the population as a whole. He discusses how his discipline gives us the tools that we need to address this problem if only people were to make the effort.

I found that although the overall method with which Chris presented his problem came across quite differently than my own problem statement we ended up drawing the same conclusion on how our discipline can help and why these problems have not already been addressed. In my problem statement I focused much more on why the problem I was researching was important to me rather than focusing on the people that it would help. I did this because the problem that I presented focuses more on personal preference and a tendency to avoid unnecessary waste while I know that many people would disagree with my desire to preserve older buildings for aesthetic reasons as well as economic reasons.  Chris’s problem is one that I think everyone can agree is something we should work to fix.

Looking at his XML formatted document the biggest difference that we had was our use of different citation styles. He also kept quotation marks in the code itself while also calling it out as a quote which lead to double quotation marks in all of his formatted annotations. We both tended to only use one type for background, summary, and relevance for each source. However Chris seemed to only use general summary every time and application relevance every time.

Overall, I do not think the Chris and I’s annotated bibliographies were all too different in format. I did enjoy the consistency in his annotation format but I do not feel like that would have worked as well considering the sources that I chose to use and for the problem that I was addressing. The one thing that I would take from reviewing Chris’s project was the straightforwardness of his problem statement. I like its simplicity and the fact that it is to the point without adding extraneous information that is unnecessary in a review of this format.

Writing our first assignment in XML format had a significant impact on the way that I wrote. Being someone who is used to writing most of my assignments in a word processor, I will admit that I did actually start the project there and then transferred it over to XML in pieces. Having that XML format and having the class defined attributes was a huge help when it came to focusing my writing and making sure that I was able to address everything that I needed to.

However, my biggest struggle with the program was the inability to format certain ways. For example, quotations were only allowed in the background and summary portions of the annotations where I had gotten a quote from a source pertaining to its audience and relevance. For my problem statement I would have liked to make it so that different statements were grouped more obviously by adding paragraphs, however the program would not allow for this type of formatting here. Additionally, as person with pretty rough spelling abilities, not having the autocorrect function that seems to have made its way into all of our typical forms of communication in today’s society was really hard. Having the lines of text continue out beyond the bounds that were easily visible in the markup program made it hard to be sure that words were correctly spelled, that grammar was used properly, or even if all of the different parts that we needed to include flowed together properly. Being able to see the formatted version online after it was synced and uploaded was incredibly helpful. I just think it would have been more helpful if that upload happened instantaneously so that we could make corrections as we went. There were a couple of occasions that I read the formatted product and realized that sentences were not stringing together in the way that I had intended or that punctuation was clearly missing in the different citations.

Overall, I think that writing the final project in XML format was a bit unnecessary and that all of the benefits that I got from having it could have been taught or displayed more easily in a simple outline of required elements. However, that could be a personal preference due to the way that my brain chooses to organize information. This XML format may make more sense to other people.