https://wiki.robojackets.org/api.php?action=feedcontributions&feedformat=atom&user=Jspalten6 2026-04-08T04:53:30Z User contributions MediaWiki 1.32.0 https://wiki.robojackets.org/index.php?title=Talk:Elections_Procedure&diff=18939 2020-05-03T02:34:55Z

<p>Jspalten6: Old Man Yells at Cloud</p> <hr /> <div>Hello I am a concerned alumnus and I have questions about the outreach chair position.<br /> I don't feel that it very specifically describes the duties.</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=17417 2019-01-07T16:52:13Z

<p>Jspalten6: /* Shop Access */</p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which obstacles which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> Additionally, to &quot;assist in presidential duties&quot; involves accepting direct delegation of Presidential duties from the President. Unfortunately, rarely do Presidents utilize this particular privilege, and, therefore, Vice Presidents should be obstinate and observant in relieving the President of tasks.<br /> <br /> === Presidential Duties in the Absence of the President ===<br /> <br /> See [[President]]<br /> <br /> === Project Management ===<br /> There is no one way to manage a project, but good project management strategies have a few things in common:<br /> <br /> * Measurable, achievable goals with accountable people supporting them<br /> <br /> * Healthy forethought around objectives<br /> <br /> * Flexibility in the face of challenges<br /> <br /> The job of the Vice President is to ensure Project Managers are making their plans and managing their projects according to good project management practices.<br /> <br /> The Vice President is involved with the President and Treasurer in reviewing and accepting [[Proposals | Project Proposals]].<br /> <br /> == De Facto Duties ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list. It is recommended to do this at least five calendar days prior to the Core Meeting to allow ample time for leaders to fill in their sections with their reports, and to allow those who wish to bring important business to the attention of officers to do so within their reports.<br /> <br /> One perennial section of a Vice President's report in Core Agendas is the Recognitions section, into which any Core member may submit a name of a member and a reason for submitting them to have their name and accomplishment read. Often this is reserved for tasks considered un-glamorous and annoying, and, by providing direct recognition and gratitude, may encourage others to volunteer for similar tasks in the future.<br /> <br /> === Key Management ===<br /> <br /> The Vice President is responsible for ensuring keys to the shop are distributed to members with need for keys and value added by possession of keys. <br /> The Vice President should make this call based on their understanding of project needs, and should confer with relevant parties as necessary.<br /> Generally, recovery and reassignment of keys should occur on a semester basis to ensure keys are all accounted for. <br /> <br /> The Vice President is also responsible for ensuring the [[People with Keys]] page is up to date. This typically manifests itself by badgering the appropriate membership to update the page. The typical rule that has been passed down is that the key holder is responsible for updating the wiki as soon as they key leaves their hands. <br /> <br /> This is imperative, because it has become a common practice for key holders to loan their keys to others. The current holder of the key must always be known, lest the risk of loss of a Georgia-owned key occur.<br /> <br /> The [[People with Keys]] page has a limited number of keys; it is important to note that, at the time of writing, these are not, in fact, all the existing keys to our shop space. Should these keys become insufficient for our key needs, the ME facilities department should be contacted using facilities@me.gatech.edu and requesting a key. This will create an RT ticket.<br /> <br /> After a request is made, wait for a response to specify when keys should be picked up.<br /> In general, keys may be picked up from MRDC 1312 at the following times:<br /> <br /> M-F, 9:00-10:30 AM &amp; 3:15-4:15 PM<br /> <br /> === Shop Access ===<br /> <br /> Historically, the duty of ensuring members have proper access to the shop has fallen on a variety of individuals, but most recently it has come under the Vice Presidential domain, and fits neatly into the overarching goal of removing obstacles to project objectives.<br /> <br /> Generally, updated lists (in the form of .csv) of GTIDs, names, and access levels should be sent to Dr. Cunefare by email.<br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=17416 2019-01-07T16:51:48Z

<p>Jspalten6: </p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which obstacles which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> Additionally, to &quot;assist in presidential duties&quot; involves accepting direct delegation of Presidential duties from the President. Unfortunately, rarely do Presidents utilize this particular privilege, and, therefore, Vice Presidents should be obstinate and observant in relieving the President of tasks.<br /> <br /> === Presidential Duties in the Absence of the President ===<br /> <br /> See [[President]]<br /> <br /> === Project Management ===<br /> There is no one way to manage a project, but good project management strategies have a few things in common:<br /> <br /> * Measurable, achievable goals with accountable people supporting them<br /> <br /> * Healthy forethought around objectives<br /> <br /> * Flexibility in the face of challenges<br /> <br /> The job of the Vice President is to ensure Project Managers are making their plans and managing their projects according to good project management practices.<br /> <br /> The Vice President is involved with the President and Treasurer in reviewing and accepting [[Proposals | Project Proposals]].<br /> <br /> == De Facto Duties ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list. It is recommended to do this at least five calendar days prior to the Core Meeting to allow ample time for leaders to fill in their sections with their reports, and to allow those who wish to bring important business to the attention of officers to do so within their reports.<br /> <br /> One perennial section of a Vice President's report in Core Agendas is the Recognitions section, into which any Core member may submit a name of a member and a reason for submitting them to have their name and accomplishment read. Often this is reserved for tasks considered un-glamorous and annoying, and, by providing direct recognition and gratitude, may encourage others to volunteer for similar tasks in the future.<br /> <br /> === Key Management ===<br /> <br /> The Vice President is responsible for ensuring keys to the shop are distributed to members with need for keys and value added by possession of keys. <br /> The Vice President should make this call based on their understanding of project needs, and should confer with relevant parties as necessary.<br /> Generally, recovery and reassignment of keys should occur on a semester basis to ensure keys are all accounted for. <br /> <br /> The Vice President is also responsible for ensuring the [[People with Keys]] page is up to date. This typically manifests itself by badgering the appropriate membership to update the page. The typical rule that has been passed down is that the key holder is responsible for updating the wiki as soon as they key leaves their hands. <br /> <br /> This is imperative, because it has become a common practice for key holders to loan their keys to others. The current holder of the key must always be known, lest the risk of loss of a Georgia-owned key occur.<br /> <br /> The [[People with Keys]] page has a limited number of keys; it is important to note that, at the time of writing, these are not, in fact, all the existing keys to our shop space. Should these keys become insufficient for our key needs, the ME facilities department should be contacted using facilities@me.gatech.edu and requesting a key. This will create an RT ticket.<br /> <br /> After a request is made, wait for a response to specify when keys should be picked up.<br /> In general, keys may be picked up from MRDC 1312 at the following times:<br /> <br /> M-F, 9:00-10:30 AM &amp; 3:15-4:15 PM<br /> <br /> === Shop Access ===<br /> <br /> Historically, the duty of ensuring members have proper access to the shop has fallen on a variety of individuals, but most recently it has come under the Vice Presidential domain, and fits neatly into the overarching goal of removing obstacles to project objectives.<br /> <br /> Generally, updated lists (in the form of .csv) of GTIDs, names, and access levels should be sent to Dr. Cunefare by email as a.<br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=17415 2019-01-07T16:50:14Z

<p>Jspalten6: /* Ex Officio Duties */</p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which obstacles which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> Additionally, a liberal interpretation of &quot;act[ion] on behalf of the President in the event of his/her absence&quot; involves accepting direct delegation of Presidential duties from the President. Unfortunately, rarely do Presidents utilize or remember this particular privilege, and, therefore, Vice Presidents should be obstinate and observant in relieving the President of tasks.<br /> <br /> === Presidential Duties in the Absence of the President ===<br /> <br /> See [[President]]<br /> <br /> === Project Management ===<br /> There is no one way to manage a project, but good project management strategies have a few things in common:<br /> <br /> * Measurable, achievable goals with accountable people supporting them<br /> <br /> * Healthy forethought around objectives<br /> <br /> * Flexibility in the face of challenges<br /> <br /> The job of the Vice President is to ensure Project Managers are making their plans and managing their projects according to good project management practices.<br /> <br /> The Vice President is involved with the President and Treasurer in reviewing and accepting [[Proposals | Project Proposals]].<br /> <br /> == De Facto Duties ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list. It is recommended to do this at least five calendar days prior to the Core Meeting to allow ample time for leaders to fill in their sections with their reports, and to allow those who wish to bring important business to the attention of officers to do so within their reports.<br /> <br /> One perennial section of a Vice President's report in Core Agendas is the Recognitions section, into which any Core member may submit a name of a member and a reason for submitting them to have their name and accomplishment read. Often this is reserved for tasks considered un-glamorous and annoying, and, by providing direct recognition and gratitude, may encourage others to volunteer for similar tasks in the future.<br /> <br /> === Key Management ===<br /> <br /> The Vice President is responsible for ensuring keys to the shop are distributed to members with need for keys and value added by possession of keys. <br /> The Vice President should make this call based on their understanding of project needs, and should confer with relevant parties as necessary.<br /> Generally, recovery and reassignment of keys should occur on a semester basis to ensure keys are all accounted for. <br /> <br /> The Vice President is also responsible for ensuring the [[People with Keys]] page is up to date. This typically manifests itself by badgering the appropriate membership to update the page. The typical rule that has been passed down is that the key holder is responsible for updating the wiki as soon as they key leaves their hands. <br /> <br /> This is imperative, because it has become a common practice for key holders to loan their keys to others. The current holder of the key must always be known, lest the risk of loss of a Georgia-owned key occur.<br /> <br /> The [[People with Keys]] page has a limited number of keys; it is important to note that, at the time of writing, these are not, in fact, all the existing keys to our shop space. Should these keys become insufficient for our key needs, the ME facilities department should be contacted using facilities@me.gatech.edu and requesting a key. This will create an RT ticket.<br /> <br /> After a request is made, wait for a response to specify when keys should be picked up.<br /> In general, keys may be picked up from MRDC 1312 at the following times:<br /> <br /> M-F, 9:00-10:30 AM &amp; 3:15-4:15 PM<br /> <br /> === Shop Access ===<br /> <br /> Historically, the duty of ensuring members have proper access to the shop has fallen on a variety of individuals, but most recently it has come under the Vice Presidential domain, and fits neatly into the overarching goal of removing obstacles to project objectives.<br /> <br /> Generally, updated lists (in the form of .csv) of GTIDs, names, and access levels should be sent to Dr. Cunefare by email as a.<br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=17414 2019-01-07T16:49:56Z

<p>Jspalten6: /* Ex Officio Duties */</p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which obstacles which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> Additionally, a liberal interpretation of &quot;act[ion] on behalf of the President in the event of his/her absence&quot; involves accepting direct delegation of Presidential duties from the President. Unfortunately, rarely do Presidents recognize or remember this particular privilege, and, therefore, Vice Presidents should be obstinate and observant in relieving the President of tasks.<br /> <br /> === Presidential Duties in the Absence of the President ===<br /> <br /> See [[President]]<br /> <br /> === Project Management ===<br /> There is no one way to manage a project, but good project management strategies have a few things in common:<br /> <br /> * Measurable, achievable goals with accountable people supporting them<br /> <br /> * Healthy forethought around objectives<br /> <br /> * Flexibility in the face of challenges<br /> <br /> The job of the Vice President is to ensure Project Managers are making their plans and managing their projects according to good project management practices.<br /> <br /> The Vice President is involved with the President and Treasurer in reviewing and accepting [[Proposals | Project Proposals]].<br /> <br /> == De Facto Duties ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list. It is recommended to do this at least five calendar days prior to the Core Meeting to allow ample time for leaders to fill in their sections with their reports, and to allow those who wish to bring important business to the attention of officers to do so within their reports.<br /> <br /> One perennial section of a Vice President's report in Core Agendas is the Recognitions section, into which any Core member may submit a name of a member and a reason for submitting them to have their name and accomplishment read. Often this is reserved for tasks considered un-glamorous and annoying, and, by providing direct recognition and gratitude, may encourage others to volunteer for similar tasks in the future.<br /> <br /> === Key Management ===<br /> <br /> The Vice President is responsible for ensuring keys to the shop are distributed to members with need for keys and value added by possession of keys. <br /> The Vice President should make this call based on their understanding of project needs, and should confer with relevant parties as necessary.<br /> Generally, recovery and reassignment of keys should occur on a semester basis to ensure keys are all accounted for. <br /> <br /> The Vice President is also responsible for ensuring the [[People with Keys]] page is up to date. This typically manifests itself by badgering the appropriate membership to update the page. The typical rule that has been passed down is that the key holder is responsible for updating the wiki as soon as they key leaves their hands. <br /> <br /> This is imperative, because it has become a common practice for key holders to loan their keys to others. The current holder of the key must always be known, lest the risk of loss of a Georgia-owned key occur.<br /> <br /> The [[People with Keys]] page has a limited number of keys; it is important to note that, at the time of writing, these are not, in fact, all the existing keys to our shop space. Should these keys become insufficient for our key needs, the ME facilities department should be contacted using facilities@me.gatech.edu and requesting a key. This will create an RT ticket.<br /> <br /> After a request is made, wait for a response to specify when keys should be picked up.<br /> In general, keys may be picked up from MRDC 1312 at the following times:<br /> <br /> M-F, 9:00-10:30 AM &amp; 3:15-4:15 PM<br /> <br /> === Shop Access ===<br /> <br /> Historically, the duty of ensuring members have proper access to the shop has fallen on a variety of individuals, but most recently it has come under the Vice Presidential domain, and fits neatly into the overarching goal of removing obstacles to project objectives.<br /> <br /> Generally, updated lists (in the form of .csv) of GTIDs, names, and access levels should be sent to Dr. Cunefare by email as a.<br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=17413 2019-01-07T16:49:22Z

<p>Jspalten6: /* Key Management */</p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which obstacles which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> Additionally, a liberal interpretation of &quot;act[ion] on behalf of the President in the even of his/her absence&quot; involves accepting direct delegation of Presidential duties from the President. Unfortunately, rarely do Presidents recognize or remember this particular privilege, and, therefore, Vice Presidents should be obstinate and observant in relieving the President of tasks.<br /> <br /> === Presidential Duties in the Absence of the President ===<br /> <br /> See [[President]]<br /> <br /> === Project Management ===<br /> There is no one way to manage a project, but good project management strategies have a few things in common:<br /> <br /> * Measurable, achievable goals with accountable people supporting them<br /> <br /> * Healthy forethought around objectives<br /> <br /> * Flexibility in the face of challenges<br /> <br /> The job of the Vice President is to ensure Project Managers are making their plans and managing their projects according to good project management practices.<br /> <br /> The Vice President is involved with the President and Treasurer in reviewing and accepting [[Proposals | Project Proposals]].<br /> <br /> == De Facto Duties ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list. It is recommended to do this at least five calendar days prior to the Core Meeting to allow ample time for leaders to fill in their sections with their reports, and to allow those who wish to bring important business to the attention of officers to do so within their reports.<br /> <br /> One perennial section of a Vice President's report in Core Agendas is the Recognitions section, into which any Core member may submit a name of a member and a reason for submitting them to have their name and accomplishment read. Often this is reserved for tasks considered un-glamorous and annoying, and, by providing direct recognition and gratitude, may encourage others to volunteer for similar tasks in the future.<br /> <br /> === Key Management ===<br /> <br /> The Vice President is responsible for ensuring keys to the shop are distributed to members with need for keys and value added by possession of keys. <br /> The Vice President should make this call based on their understanding of project needs, and should confer with relevant parties as necessary.<br /> Generally, recovery and reassignment of keys should occur on a semester basis to ensure keys are all accounted for. <br /> <br /> The Vice President is also responsible for ensuring the [[People with Keys]] page is up to date. This typically manifests itself by badgering the appropriate membership to update the page. The typical rule that has been passed down is that the key holder is responsible for updating the wiki as soon as they key leaves their hands. <br /> <br /> This is imperative, because it has become a common practice for key holders to loan their keys to others. The current holder of the key must always be known, lest the risk of loss of a Georgia-owned key occur.<br /> <br /> The [[People with Keys]] page has a limited number of keys; it is important to note that, at the time of writing, these are not, in fact, all the existing keys to our shop space. Should these keys become insufficient for our key needs, the ME facilities department should be contacted using facilities@me.gatech.edu and requesting a key. This will create an RT ticket.<br /> <br /> After a request is made, wait for a response to specify when keys should be picked up.<br /> In general, keys may be picked up from MRDC 1312 at the following times:<br /> <br /> M-F, 9:00-10:30 AM &amp; 3:15-4:15 PM<br /> <br /> === Shop Access ===<br /> <br /> Historically, the duty of ensuring members have proper access to the shop has fallen on a variety of individuals, but most recently it has come under the Vice Presidential domain, and fits neatly into the overarching goal of removing obstacles to project objectives.<br /> <br /> Generally, updated lists (in the form of .csv) of GTIDs, names, and access levels should be sent to Dr. Cunefare by email as a.<br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=17412 2019-01-07T16:49:03Z

<p>Jspalten6: /* Key Management */</p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which obstacles which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> Additionally, a liberal interpretation of &quot;act[ion] on behalf of the President in the even of his/her absence&quot; involves accepting direct delegation of Presidential duties from the President. Unfortunately, rarely do Presidents recognize or remember this particular privilege, and, therefore, Vice Presidents should be obstinate and observant in relieving the President of tasks.<br /> <br /> === Presidential Duties in the Absence of the President ===<br /> <br /> See [[President]]<br /> <br /> === Project Management ===<br /> There is no one way to manage a project, but good project management strategies have a few things in common:<br /> <br /> * Measurable, achievable goals with accountable people supporting them<br /> <br /> * Healthy forethought around objectives<br /> <br /> * Flexibility in the face of challenges<br /> <br /> The job of the Vice President is to ensure Project Managers are making their plans and managing their projects according to good project management practices.<br /> <br /> The Vice President is involved with the President and Treasurer in reviewing and accepting [[Proposals | Project Proposals]].<br /> <br /> == De Facto Duties ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list. It is recommended to do this at least five calendar days prior to the Core Meeting to allow ample time for leaders to fill in their sections with their reports, and to allow those who wish to bring important business to the attention of officers to do so within their reports.<br /> <br /> One perennial section of a Vice President's report in Core Agendas is the Recognitions section, into which any Core member may submit a name of a member and a reason for submitting them to have their name and accomplishment read. Often this is reserved for tasks considered un-glamorous and annoying, and, by providing direct recognition and gratitude, may encourage others to volunteer for similar tasks in the future.<br /> <br /> === Key Management ===<br /> <br /> The Vice President is responsible for ensuring keys to the shop are distributed to members with need for keys and value added by possession of keys. <br /> The Vice President should make this call based on their understanding of project needs, and should confer with relevant parties as necessary.<br /> Generally, recovery and reassignment of keys should occur on a semester basis to ensure keys are all accounted for. <br /> <br /> The Vice President is also responsible for ensuring the [[People with Keys]] page is up to date. This typically manifests itself by badgering the appropriate membership to update the page. The typical rule that has been passed down is that the key holder is responsible for updating the wiki as soon as they key leaves their hands. <br /> <br /> This is imperative, because it has become a common practice for key holders to loan their keys to others. The current holder of the key must always be known, lest the risk of loss of a Georgia-owned key occur.<br /> <br /> The [[People with Keys]] page has a limited number of keys; it is important to note that, at the time of writing, these are not, in fact, all the existing keys to our shop space. Should these keys become insufficient for our key needs, the ME facilities department should be contacted using facilities@me.gatech.edu and requesting a key. This will create an RT ticket.<br /> <br /> After a request is made, wait for a response to specify when keys should be picked up.<br /> In general, keys may be picked up from MRDC 1312 at the following times:<br /> M-F, 9:00-10:30 AM &amp; 3:15-4:15 PM<br /> <br /> === Shop Access ===<br /> <br /> Historically, the duty of ensuring members have proper access to the shop has fallen on a variety of individuals, but most recently it has come under the Vice Presidential domain, and fits neatly into the overarching goal of removing obstacles to project objectives.<br /> <br /> Generally, updated lists (in the form of .csv) of GTIDs, names, and access levels should be sent to Dr. Cunefare by email as a.<br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=17411 2019-01-07T15:58:28Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |Evan Peterson<br /> |-<br /> | 3SB6: 4<br /> |Dallas Downing<br /> |-<br /> | 3SB6: 5<br /> |Jonathan Spalten<br /> |-<br /> | 3SB6: 7<br /> |Vijay Srivastava<br /> |-<br /> | 3SB6: 8<br /> |Matt White<br /> |-<br /> | 3SB6: 9<br /> | Carrie Wehmeyer<br /> |-<br /> | 3SB6: 12<br /> | Evan Strat<br /> |-<br /> | 3SB6: 14<br /> | Josh Oldenburg<br /> |-<br /> | 3SB6: 15<br /> | Tomas Osses<br /> |-<br /> | 3SB6: 18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6: 19<br /> | Will Stuckey<br /> |-<br /> | 3SB6: 20<br /> | Andrew Tuttle<br /> |-<br /> | 3SB6: 21<br /> | Joseph Neiger<br /> |-<br /> | 3SB6: 22<br /> | Andrew Chang<br /> |-<br /> | 3SB6: 24<br /> | Luke Pasquarelli<br /> |-<br /> | 3SB6: 27<br /> | Juan Almagro<br /> |-<br /> | 3SB6: 28<br /> | Joseph Spall<br /> |-<br /> | 3SB6: 29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6: 30<br /> | James O'Connor<br /> |-<br /> | 3SB6: 31<br /> | Daniil Budanov<br /> |-<br /> |3SB6: 33<br /> | Kristaps Berzinch<br /> |-<br /> |3SB6: 34<br /> | Jason Gibson<br /> |-<br /> |3SB6: 35<br /> | Cory Stine<br /> |-<br /> |3SB6: 36<br /> | Varun Madabushi<br /> |-<br /> |3SB6: 38<br /> | James Reed<br /> |-<br /> |3SB6: 39<br /> | Nico Castro<br /> |-<br /> |3SB6: 40<br /> |Sarah Storer<br /> |-<br /> |3SB6: 41<br /> |Ryan Waldheim<br /> |-<br /> |3SB6: 43<br /> |Young Won<br /> |-<br /> |3SB6: 44<br /> |Matthew Woodward<br /> |-<br /> |3SB6: 45<br /> |Evan Bretl<br /> |}<br /> <br /> <br /> [[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=17264 2018-11-27T15:48:20Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |Evan Peterson<br /> |-<br /> | 3SB6: 4<br /> |Dallas Downing<br /> |-<br /> | 3SB6: 5<br /> |Jonathan Spalten<br /> |-<br /> | 3SB6: 7<br /> |Vijay Srivastava<br /> |-<br /> | 3SB6: 8<br /> |Matt White<br /> |-<br /> | 3SB6: 9<br /> | Juan Elizondo<br /> |-<br /> | 3SB6:12<br /> | Evan Strat<br /> |-<br /> | 3SB6:14<br /> | Josh Oldenburg<br /> |-<br /> | 3SB6:15<br /> | Tomas Osses<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> | Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | Andrew Tuttle<br /> |-<br /> | 3SB6:21<br /> | Joseph Neiger<br /> |-<br /> | 3SB6:22<br /> | Hank Hellstrom<br /> |-<br /> | 3SB6:24<br /> | Luke Pasquarelli<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> | James O'Connor<br /> |-<br /> | 3SB6:31<br /> | Daniil Budanov<br /> |-<br /> |3SB6:33<br /> | Kristaps Berzinch<br /> |-<br /> |3SB6:34<br /> | Jason Gibson<br /> |-<br /> |3SB6:35<br /> | Cory Stine<br /> |-<br /> |3SB6:36<br /> | Varun Madabushi<br /> |-<br /> |3SB6:38<br /> | James Reed<br /> |-<br /> |3SB6:39<br /> | Nico Castro<br /> |-<br /> |3SB6: 40<br /> |Sarah Storer<br /> |-<br /> |3SB6: 41<br /> |Ryan Waldheim<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6:45<br /> |Evan Bretl<br /> |}<br /> <br /> <br /> [[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=17263 2018-11-27T15:47:54Z

<p>Jspalten6: </p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which obstacles which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> Additionally, a liberal interpretation of &quot;act[ion] on behalf of the President in the even of his/her absence&quot; involves accepting direct delegation of Presidential duties from the President. Unfortunately, rarely do Presidents recognize or remember this particular privilege, and, therefore, Vice Presidents should be obstinate and observant in relieving the President of tasks.<br /> <br /> === Presidential Duties in the Absence of the President ===<br /> <br /> See [[President]]<br /> <br /> === Project Management ===<br /> There is no one way to manage a project, but good project management strategies have a few things in common:<br /> <br /> * Measurable, achievable goals with accountable people supporting them<br /> <br /> * Healthy forethought around objectives<br /> <br /> * Flexibility in the face of challenges<br /> <br /> The job of the Vice President is to ensure Project Managers are making their plans and managing their projects according to good project management practices.<br /> <br /> The Vice President is involved with the President and Treasurer in reviewing and accepting [[Proposals | Project Proposals]].<br /> <br /> == De Facto Duties ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list. It is recommended to do this at least five calendar days prior to the Core Meeting to allow ample time for leaders to fill in their sections with their reports, and to allow those who wish to bring important business to the attention of officers to do so within their reports.<br /> <br /> One perennial section of a Vice President's report in Core Agendas is the Recognitions section, into which any Core member may submit a name of a member and a reason for submitting them to have their name and accomplishment read. Often this is reserved for tasks considered un-glamorous and annoying, and, by providing direct recognition and gratitude, may encourage others to volunteer for similar tasks in the future.<br /> <br /> === Key Management ===<br /> <br /> The Vice President is responsible for ensuring keys to the shop are distributed to members with need for keys and value added by possession of keys. <br /> The Vice President should make this call based on their understanding of project needs, and should confer with relevant parties as necessary.<br /> Generally, recovery and reassignment of keys should occur on a semester basis to ensure keys are all accounted for. <br /> <br /> The Vice President is also responsible for ensuring the [[People with Keys]] page is up to date. This typically manifests itself by badgering the appropriate membership to update the page. The typical rule that has been passed down is that the key holder is responsible for updating the wiki as soon as they key leaves their hands. <br /> <br /> This is imperative, because it has become a common practice for key holders to loan their keys to others. The current holder of the key must always be known, lest the risk of loss of a Georgia-owned key occur.<br /> <br /> The [[People with Keys]] page has a limited number of keys; it is important to note that, at the time of writing, these are not, in fact, all the existing keys to our shop space. Should these keys become insufficient for our key needs, the Administrative Operations Coordinator at the ME department, Dorothy McDuffie-Alexander, at the time of writing, should be contacted to coordinate assigning new keys to members.<br /> <br /> === Shop Access ===<br /> <br /> Historically, the duty of ensuring members have proper access to the shop has fallen on a variety of individuals, but most recently it has come under the Vice Presidential domain, and fits neatly into the overarching goal of removing obstacles to project objectives.<br /> <br /> Generally, updated lists (in the form of .csv) of GTIDs, names, and access levels should be sent to Dr. Cunefare by email as a.<br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=17067 2018-10-28T22:10:32Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |Evan Peterson<br /> |-<br /> | 3SB6: 4<br /> |Dallas Downing<br /> |-<br /> | 3SB6: 5<br /> |Jonathan Spalten<br /> |-<br /> | 3SB6: 7<br /> |Vijay Srivastava<br /> |-<br /> | 3SB6: 8<br /> |Matt White<br /> |-<br /> | 3SB6: 9<br /> | Carrie Wehmeyer<br /> |-<br /> | 3SB6:12<br /> | Evan Strat<br /> |-<br /> | 3SB6:14<br /> | Josh Oldenburg<br /> |-<br /> | 3SB6:15<br /> | Tomas Osses<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> | Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:21<br /> | Joseph Neiger<br /> |-<br /> | 3SB6:22<br /> | Hank Hellstrom<br /> |-<br /> | 3SB6:23<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:24<br /> | Luke Pasquarelli<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> | James O'Connor<br /> |-<br /> | 3SB6:31<br /> | Daniil Budanov<br /> |-<br /> |3SB6:33<br /> | Kristaps Berzinch<br /> |-<br /> |3SB6:34<br /> | Jason Gibson<br /> |-<br /> |3SB6:36<br /> | Varun Madabushi<br /> |-<br /> |3SB6:38<br /> | James Reed<br /> |-<br /> |3SB6:39<br /> | Nico Castro<br /> |-<br /> |3SB6: 40<br /> |Sarah Storer<br /> |-<br /> |3SB6: 41<br /> |Ryan Waldheim<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6:45<br /> |Evan Bretl<br /> |}<br /> <br /> <br /> [[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=17066 2018-10-26T02:26:53Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |Evan Peterson<br /> |-<br /> | 3SB6: 4<br /> |Dallas Downing<br /> |-<br /> | 3SB6: 5<br /> |Jonathan Spalten<br /> |-<br /> | 3SB6: 7<br /> |Vijay Srivastava<br /> |-<br /> | 3SB6: 8<br /> |Matt White<br /> |-<br /> | 3SB6: 9<br /> | Carrie Wehmeyer<br /> |-<br /> | 3SB6:12<br /> | Evan Strat<br /> |-<br /> | 3SB6:14<br /> | Josh Oldenburg<br /> |-<br /> | 3SB6:15<br /> | Tomas Osses<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> | Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | Jonathan Spalten<br /> |-<br /> | 3SB6:21<br /> | Joseph Neiger<br /> |-<br /> | 3SB6:22<br /> | Hank Hellstrom<br /> |-<br /> | 3SB6:23<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:24<br /> | Luke Pasquarelli<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> | James O'Connor<br /> |-<br /> | 3SB6:31<br /> | Daniil Budanov<br /> |-<br /> |3SB6:33<br /> | Kristaps Berzinch<br /> |-<br /> |3SB6:34<br /> | Jason Gibson<br /> |-<br /> |3SB6:36<br /> | Varun Madabushi<br /> |-<br /> |3SB6:38<br /> | James Reed<br /> |-<br /> |3SB6:39<br /> | Nico Castro<br /> |-<br /> |3SB6: 40<br /> |Sarah Storer<br /> |-<br /> |3SB6: 41<br /> |Ryan Waldheim<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6:45<br /> |Evan Bretl<br /> |}<br /> <br /> <br /> [[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=16976 2018-09-01T22:47:39Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |Evan Peterson<br /> |-<br /> | 3SB6: 4<br /> |Dallas Downing<br /> |-<br /> | 3SB6: 5<br /> |Jonathan Spalten<br /> |-<br /> | 3SB6: 7<br /> |Vijay Srivastava<br /> |-<br /> | 3SB6: 8<br /> |Matt White<br /> |-<br /> | 3SB6: 9<br /> | Carrie Wehmeyer<br /> |-<br /> | 3SB6:12<br /> | John Carnahan<br /> |-<br /> | 3SB6:14<br /> | Jon Jones<br /> |-<br /> | 3SB6:15<br /> | Tomas Osses<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> | Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | Cory Stine<br /> |-<br /> | 3SB6:21<br /> | Jeremy Feltracco<br /> |-<br /> | 3SB6:22<br /> | Hank Hellstrom<br /> |-<br /> | 3SB6:23<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:24<br /> | Luke Pasquarelli<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> | James O'Connor<br /> |-<br /> | 3SB6:31<br /> | Daniil Budanov<br /> |-<br /> |3SB6:33<br /> | Kristaps Berzinch<br /> |-<br /> |3SB6:34<br /> | Jason Gibson<br /> |-<br /> |3SB6:36<br /> | Varun Madabushi<br /> |-<br /> |3SB6:38<br /> | James Reed<br /> |-<br /> |3SB6:39<br /> | Nico Castro<br /> |-<br /> |3SB6: 40<br /> |Sarah Storer<br /> |-<br /> |3SB6: 41<br /> |Noah Daugherty<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6:45<br /> |Evan Bretl<br /> |}<br /> <br /> <br /> [[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=16955 2018-08-28T01:27:30Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |Evan Peterson<br /> |-<br /> | 3SB6: 4<br /> |Dallas Downing<br /> |-<br /> | 3SB6: 5<br /> |Jonathan Spalten<br /> |-<br /> | 3SB6: 7<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 8<br /> |Collin Avidano<br /> |-<br /> | 3SB6: 9<br /> | Carrie Wehmeyer<br /> |-<br /> | 3SB6:12<br /> | John Carnahan<br /> |-<br /> | 3SB6:14<br /> | Jon Jones<br /> |-<br /> | 3SB6:15<br /> | Tomas Osses<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> | Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | Cory Stine<br /> |-<br /> | 3SB6:21<br /> | Jeremy Feltracco<br /> |-<br /> | 3SB6:22<br /> | Hank Hellstrom<br /> |-<br /> | 3SB6:23<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:24<br /> | Luke Pasquarelli<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> | James O'Connor<br /> |-<br /> | 3SB6:31<br /> | Daniil Budanov<br /> |-<br /> |3SB6:33<br /> | Kristaps Berzinch<br /> |-<br /> |3SB6:34<br /> | Jason Gibson<br /> |-<br /> |3SB6:36<br /> | Varun Madabushi<br /> |-<br /> |3SB6:38<br /> | James Reed<br /> |-<br /> |3SB6:39<br /> | Nico Castro<br /> |-<br /> |3SB6: 40<br /> |Sarah Storer<br /> |-<br /> |3SB6: 41<br /> |Noah Daugherty<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6: 45<br /> |''Unassigned''<br /> |}<br /> <br /> <br /> [[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16947 2018-08-21T03:05:51Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_1.0.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objective Statements ====<br /> <br /> To define year long objectives, a few (3-4) short bullets, hereafter referred to as objective statements, should be written to concisely define the focus of the project in the coming year. The objective statements should be focused on desired changes and improvements in approach from year to year. An objective statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements or changes to the approach to designing and building robots relative to the past year of the project. These objectives are at the top of the objectives pyramid, as the goals expressed in the objectives statements must be supported by all work done as a part of the team.<br /> <br /> Each objective statement should have an associated justification. The justification explains ''why'' each objective statement is important, and, hence, why it is a goal. These justifications are for the benefit of both Core officers in understanding goals for the coming year, as well as for future generations of team leadership.<br /> <br /> ==== Subteam Objective Statements ====<br /> <br /> From there, subteam objectives should be defined in the same format as the objective statements. Each subteam objective statement should support the overall goals of the objectives statements. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year. Subteam objectives do not have to be based solely on the objectives statements, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation. Additionally, subteam objective statements should also have associated justifications, for the same reasons as the overall objective statements.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week or day-to-day level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. Tasks should also have justifications, for the same reasons as objective statements and subteam objective statements. These justifications should identify the associated subteam objective, as well as explain the importance of the task.<br /> <br /> ==== Milestones ====<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> To more easily see connections between tasks and milestones, the list of milestones should be grouped with the subteam objectives and tasks.<br /> <br /> ===== Milestones Example =====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into capital outlays/tooling and Travel/Registration.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=16945 2018-08-20T22:25:29Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |Evan Peterson<br /> |-<br /> | 3SB6: 4<br /> |Dallas Downing<br /> |-<br /> | 3SB6: 5<br /> |Jonathan Spalten<br /> |-<br /> | 3SB6: 7<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 8<br /> |Collin Avidano<br /> |-<br /> | 3SB6: 9<br /> | Carrie Wehmeyer<br /> |-<br /> | 3SB6:12<br /> | John Carnahan<br /> |-<br /> | 3SB6:14<br /> | Jon Jones<br /> |-<br /> | 3SB6:15<br /> | Tomas Osses<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> | Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | Cory Stine<br /> |-<br /> | 3SB6:21<br /> | Jeremy Feltracco<br /> |-<br /> | 3SB6:22<br /> | Hank Hellstrom<br /> |-<br /> | 3SB6:23<br /> | Carrie Li<br /> |-<br /> | 3SB6:24<br /> | Luke Pasquarelli<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> |''Unassigned''<br /> |-<br /> | 3SB6:31<br /> | Daniil Budanov<br /> |-<br /> |3SB6:33<br /> | Kristaps Berzinch<br /> |-<br /> |3SB6:34<br /> | Jason Gibson<br /> |-<br /> |3SB6:36<br /> | Varun Madabushi<br /> |-<br /> |3SB6:38<br /> |''Unassigned''<br /> |-<br /> |3SB6:39<br /> |''Unassigned''<br /> |-<br /> |3SB6: 40<br /> |Sarah Storer<br /> |-<br /> |3SB6: 41<br /> |Noah Daugherty<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6: 45<br /> |''Unassigned''<br /> |}<br /> <br /> <br /> [[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=16944 2018-08-20T22:24:43Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |''Evan Peterson ''<br /> |-<br /> | 3SB6: 4<br /> |Dallas Downing<br /> |-<br /> | 3SB6: 5<br /> |Jonathan Spalten<br /> |-<br /> | 3SB6: 7<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 8<br /> |Collin Avidano<br /> |-<br /> | 3SB6: 9<br /> | Carrie Wehmeyer<br /> |-<br /> | 3SB6:12<br /> | John Carnahan<br /> |-<br /> | 3SB6:14<br /> | Jon Jones<br /> |-<br /> | 3SB6:15<br /> | Tomas Osses<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> | Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | Cory Stine<br /> |-<br /> | 3SB6:21<br /> | Jeremy Feltracco<br /> |-<br /> | 3SB6:22<br /> | Hank Hellstrom<br /> |-<br /> | 3SB6:23<br /> | Carrie Li<br /> |-<br /> | 3SB6:24<br /> | Luke Pasquarelli<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> |''Unassigned''<br /> |-<br /> | 3SB6:31<br /> | Daniil Budanov<br /> |-<br /> |3SB6:33<br /> | Kristaps Berzinch<br /> |-<br /> |3SB6:34<br /> | Jason Gibson<br /> |-<br /> |3SB6:36<br /> | Varun Madabushi<br /> |-<br /> |3SB6:38<br /> |''Unassigned''<br /> |-<br /> |3SB6:39<br /> |''Unassigned''<br /> |-<br /> |3SB6: 40<br /> |Sarah Storer<br /> |-<br /> |3SB6: 41<br /> |Noah Daugherty<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6: 45<br /> |''Unassigned''<br /> |}<br /> <br /> <br /> [[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=16943 2018-08-20T22:23:35Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |''Evan Peterson ''<br /> |-<br /> | 3SB6: 4<br /> |Dallas Downing<br /> |-<br /> | 3SB6: 5<br /> |Jonathan Spalten<br /> |-<br /> | 3SB6: 7<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 8<br /> |Collin Avidano<br /> |-<br /> | 3SB6: 9<br /> | Carrie Wehmeyer<br /> |-<br /> | 3SB6:12<br /> | John Carnahan<br /> |-<br /> | 3SB6:14<br /> | ''Jon Jones''<br /> |-<br /> | 3SB6:15<br /> | ''Tomas Osses''<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> |Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | Cory Stine<br /> |-<br /> | 3SB6:21<br /> | Jeremy Feltracco<br /> |-<br /> | 3SB6:22<br /> | Hank Hellstrom<br /> |-<br /> | 3SB6:23<br /> | Carrie Li<br /> |-<br /> | 3SB6:24<br /> | Luke Pasquarelli<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> |''Unassigned''<br /> |-<br /> | 3SB6:31<br /> |Daniil Budanov<br /> |-<br /> |3SB6:33<br /> |Kristaps Berzinch<br /> |-<br /> |3SB6:34<br /> |Jason Gibson<br /> |-<br /> |3SB6:36<br /> |Varun Madabushi<br /> |-<br /> |3SB6:38<br /> |''Unassigned''<br /> |-<br /> |3SB6:39<br /> |''Unassigned''<br /> |-<br /> |3SB6: 40<br /> |Sarah Storer<br /> |-<br /> |3SB6: 41<br /> |Noah Daugherty<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6: 45<br /> |''Unassigned''<br /> |}<br /> <br /> <br /> [[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=16942 2018-08-20T22:23:12Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |''Evan Peterson ''<br /> |-<br /> | 3SB6: 4<br /> |Dallas Downing<br /> |-<br /> | 3SB6: 5<br /> |Jonathan Spalten<br /> |-<br /> | 3SB6: 7<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 8<br /> |Collin Avidano<br /> |-<br /> | 3SB6: 9<br /> | Carrie Wehmeyer<br /> |-<br /> | 3SB6:12<br /> | John Carnahan<br /> |-<br /> | 3SB6:14<br /> | ''Jon Jones''<br /> |-<br /> | 3SB6:15<br /> | ''Tomas Osses''<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> |Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | Cory Stine<br /> |-<br /> | 3SB6:21<br /> | Jeremy Feltracco<br /> |-<br /> | 3SB6:22<br /> | Hank Hellstrom<br /> |-<br /> | 3SB6:23<br /> | Carrie Li<br /> |-<br /> | 3SB6:24<br /> | Luke Pasquarelli<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> |''Unassigned''<br /> |-<br /> | 3SB6:31<br /> |Daniil Budanov<br /> |-<br /> |3SB6:33<br /> |''Unassigned''<br /> |-<br /> |3SB6:34<br /> |Jason Gibson<br /> |-<br /> |3SB6:36<br /> |Varun Madabushi<br /> |-<br /> |3SB6:38<br /> |''Unassigned''<br /> |-<br /> |3SB6:39<br /> |''Unassigned''<br /> |-<br /> |3SB6: 40<br /> |Sarah Storer<br /> |-<br /> |3SB6: 41<br /> |Noah Daugherty<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6: 45<br /> |''Unassigned''<br /> |}<br /> <br /> <br /> [[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16933 2018-08-15T19:32:23Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_1.0.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objective Statements ====<br /> <br /> To define year long objectives, a few (3-4) short bullets, hereafter referred to as objective statements, should be written to concisely define the focus of the project in the coming year. The objective statements should be focused on desired changes and improvements in approach from year to year. An objective statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements or changes to the approach to designing and building robots relative to the past year of the project. These objectives are at the top of the objectives pyramid, as the goals expressed in the objectives statements must be supported by all work done as a part of the team.<br /> <br /> Each objective statement should have an associated justification. The justification explains ''why'' each objective statement is important, and, hence, why it is a goal. These justifications are for the benefit of both Core officers in understanding goals for the coming year, as well as for future generations of team leadership.<br /> <br /> ==== Subteam Objective Statements ====<br /> <br /> From there, subteam objectives should be defined in the same format as the objective statements. Each subteam objective statement should support the overall goals of the objectives statements. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year. Subteam objectives do not have to be based solely on the objectives statements, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation. Additionally, subteam objective statements should also have associated justifications, for the same reasons as the overall objective statements.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week or day-to-day level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. Tasks should also have justifications, for the same reasons as objective statements and subteam objective statements. These justifications should identify the associated subteam objective, as well as explain the importance of the task.<br /> <br /> ==== Milestones ====<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> To more easily see connections between tasks and milestones, the list of milestones should be grouped with the subteam objectives and tasks.<br /> <br /> ===== Milestones Example =====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items it is requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16932 2018-08-15T19:29:35Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_1.0.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objective Statements ====<br /> <br /> To define year long objectives, a few (3-4) short bullets, hereafter referred to as objective statements, should be written to concisely define the focus of the project in the coming year. The objective statements should be focused on desired changes and improvements in approach from year to year. An objective statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements or changes to the approach to designing and building robots relative to the past year of the project. These objectives are at the top of the objectives pyramid, as the goals expressed in the objectives statements must be supported by all work done as a part of the team.<br /> <br /> Each objective statement should have an associated justification. The justification explains ''why'' each objective statement is important, and, hence, why it is a goal. These justifications are for the benefit of both Core officers in understanding goals for the coming year, as well as for future generations of team leadership.<br /> <br /> ==== Subteam Objective Statements ====<br /> <br /> From there, subteam objectives should be defined in the same format as the objective statements. Each subteam objective statement should support the overall goals of the objectives statements. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year. Subteam objectives do not have to be based solely on the objectives statements, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation. Additionally, subteam objective statements should also have associated justifications, for the same reasons as the overall objective statements.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week or day-to-day level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. Tasks should also have justifications, for the same reasons as objective statements and subteam objective statements. These justifications should identify the associated subteam objective, as well as explain the importance of the task.<br /> <br /> ==== Milestones ====<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> To more easily see connections between tasks and milestones, milestones should immediately follow their corresponding tasks in the proposal.<br /> <br /> ===== Milestones Example =====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items it is requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16931 2018-08-15T03:35:36Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_1.0.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objective Statements ====<br /> <br /> To define year long objectives, a few (3-4) short bullets, hereafter referred to as objective statements, should be written to concisely define the focus of the project in the coming year. The objective statements should be focused on desired changes and improvements in approach from year to year. An objective statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements or changes to the approach to designing and building robots relative to the past year of the project. These objectives are at the top of the objectives pyramid, as the goals expressed in the objectives statements must be supported by all work done as a part of the team.<br /> <br /> Each objective statement should have an associated justification. The justification explains ''why'' each objective statement is important, and, hence, why it is a goal. These justifications are for the benefit of both Core officers in understanding goals for the coming year, as well as for future generations of team leadership.<br /> <br /> ==== Subteam Objective Statements ====<br /> <br /> From there, subteam objectives should be defined in the same format as the objective statements. Each subteam objective statement should support the overall goals of the objectives statements. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year. Subteam objectives do not have to be based solely on the objectives statements, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation. Additionally, subteam objective statements should also have associated justifications, for the same reasons as the overall objective statements.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week or day-to-day level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. Tasks should also have justifications, for the same reasons as objective statements and subteam objective statements. These justifications should identify the associated subteam objective, as well as explain the importance of the task.<br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items it is requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16930 2018-08-15T03:34:34Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_1.0.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objective Statements ====<br /> <br /> To define year long objectives, a few (3-4) short bullets, hereafter referred to as objective statements, should be written to concisely define the focus of the project in the coming year. The objective statements should be focused on desired changes and improvements in approach from year to year. An objective statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements or changes to the approach to designing and building robots relative to the past year of the project. These objectives are at the top of the objectives pyramid, as the goals expressed in the objectives statements must be supported by all work done as a part of the team.<br /> <br /> Each objective statement should have an associated justification. The justification explains ''why'' each objective statement is important, and, hence, why it is a goal. These justifications are for the benefit of both Core officers in understanding goals for the coming year, as well as for future generations of team leadership.<br /> <br /> ==== Subteam Objective Statements ====<br /> <br /> From there, subteam objectives should be defined in the same format as the objective statements. Each subteam objective statement should support the overall goals of the objectives statements. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year. Subteam objectives do not have to be based solely on the objectives statements, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation. Additionally, subteam objective statements should also have associated justifications, for the same reasons as the overall objective statements.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week or day-to-day level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. Tasks should also have justifications, for the same reasons as objective statements and subteam objective statements. These justifications should identify the associated subteam objective, as well as explain the importance of the task.<br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16929 2018-08-14T02:10:59Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_1.0.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objective Statements ====<br /> <br /> To define year long objectives, a few (3-4) short bullets, hereafter referred to as objective statements, should be written to concisely define the focus of the project in the coming year. The objective statements should be focused on desired changes and improvements in approach from year to year. An objective statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements or changes to the approach to designing and building robots relative to the past year of the project. These objectives are at the top of the objectives pyramid, as the goals expressed in the objectives statements must be supported by all work done as a part of the team.<br /> <br /> Each objective statement should have an associated justification. The justification explains ''why'' each objective statement is important, and, hence, why it is a goal. These justifications are for the benefit of both Core officers in understanding goals for the coming year, as well as for future generations of team leadership.<br /> <br /> ==== Subteam Objective Statements ====<br /> <br /> From there, subteam objectives should be defined in the same format as the objective statements. Each subteam objective statement should support the overall goals of the objectives statements. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year. Subteam objectives do not have to be based solely on the objectives statements, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation. Additionally, subteam objective statements should also have associated justifications, for the same reasons as the overall objective statements.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week or day-to-day level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. Tasks should also have justifications, for the same reasons as objective statements and subteam objective statements. These justifications should identify the associated subteam objective, as well as explain the importance of the task.<br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16928 2018-08-14T02:08:05Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_1.0.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objective Statements ====<br /> <br /> To define year long objectives, a few (3-4) short bullets, hereafter referred to as objective statements, should be written to concisely define the focus of the project in the coming year. The objective statements should be focused on desired changes and improvements in approach from year to year. An objective statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements or changes to the approach to designing and building robots relative to the past year of the project. These objectives are at the top of the objectives pyramid, as the goals expressed in the objectives statements must be supported by all work done as a part of the team.<br /> <br /> Each objective statement should have an associated justification. The justification explains ''why'' each objective statement is important, and, hence, why it is a goal. These justifications are for the benefit of both Core officers in understanding goals for the coming year, as well as for future generations of team leadership.<br /> <br /> ==== Subteam Objective Statements ====<br /> <br /> From there, subteam objective statements should be defined. Subteam objective statements are objectives statements on a subteam level. Each subteam objective statement should support the overall goals of the objectives statements. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year. Subteam objectives do not have to be based solely on the objectives statements, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation. Additionally, subteam objective statements should also have associated justifications, for the same reasons as the overall objective statements.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week or day-to-day level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. Tasks should also have justifications, for the same reasons as objective statements and subteam objective statements. These justifications should identify the associated subteam objective, as well as explain the importance of the task.<br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=File:Objectives_Pyramid_Version_1.0.png&diff=16927 2018-08-14T02:07:43Z

<p>Jspalten6: Objectives Pyramid as of 8/13</p> <hr /> <div>Objectives Pyramid as of 8/13</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16926 2018-08-14T01:39:10Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.1.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objective Statements ====<br /> <br /> To define year long objectives, a few (3-4) short bullets, hereafter referred to as objective statements, should be written to concisely define the focus of the project in the coming year. The objective statements should be focused on desired changes and improvements in approach from year to year. An objective statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements or changes to the approach to designing and building robots relative to the past year of the project. These objectives are at the top of the objectives pyramid, as the goals expressed in the objectives statements must be supported by all work done as a part of the team.<br /> <br /> Each objective statement should have an associated justification. The justification explains ''why'' each objective statement is important, and, hence, why it is a goal. These justifications are for the benefit of both Core officers in understanding goals for the coming year, as well as for future generations of team leadership.<br /> <br /> ==== Subteam Objective Statements ====<br /> <br /> From there, subteam objective statements should be defined. Subteam objective statements are objectives statements on a subteam level. Each subteam objective statement should support the overall goals of the objectives statements. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year. Subteam objectives do not have to be based solely on the objectives statements, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation. Additionally, subteam objective statements should also have associated justifications, for the same reasons as the overall objective statements.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week or day-to-day level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. Tasks should also have justifications, for the same reasons as objective statements and subteam objective statements. These justifications should identify the associated subteam objective, as well as explain the importance of the task.<br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16908 2018-08-10T02:01:56Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.1.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on desired changes and improvements in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements in approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> ==== Example ====<br /> Improve sustainability&lt;sup&gt;1&lt;/sup&gt; and accountability&lt;sup&gt;2&lt;/sup&gt; in RoboJackets, and foster collaboration&lt;sup&gt;3&lt;/sup&gt; with knowledgeable entities&lt;sup&gt;4&lt;/sup&gt;. <br /> <br /> #Maintaining or improving management, technical, and human resources<br /> #Understanding of expectations and ownership of one’s actions<br /> #Exchanging of organizational and technical knowledge<br /> #External organizations and internal membership<br /> <br /> <br /> ==== Subteam Objective Statement ====<br /> <br /> From there, a subteam objective statement should be defined. A subteam objective statement is an objectives statement on a subteam level. Each subteam objective statement should support the overall goals of the objectives statement. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year, and corresponding milestones. Subteam objectives do not have to be based solely on the objective statement, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. <br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16907 2018-08-10T01:47:24Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.1.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on desired changes and improvements in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements in approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> ==== Example ====<br /> Improve sustainability&lt;sup&gt;1&lt;/sup&gt; and accountability&lt;sup&gt;2&lt;/sup&gt; in RoboJackets, and foster collaboration&lt;sup&gt;3&lt;/sup&gt; with knowledgeable entities&lt;sup&gt;4&lt;/sup&gt;. <br /> <br /> #Maintaining or improving management, technical, and human resources<br /> #Understanding of expectations and ownership of one’s actions<br /> #Exchanging of organizational and technical knowledge<br /> #External organizations and internal membership<br /> <br /> <br /> ==== Subteam Objective Statement ====<br /> <br /> From there, a subteam objective statement should be defined. A subteam objective statement is an objectives statement on a subteam level. Each subteam objective statement should support the overall goals of the objectives statement. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year, and corresponding milestones. Subteam objectives do not have to be based solely on the objective statement, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. <br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Yearly_Housekeeping&diff=16906 2018-08-10T01:32:33Z

<p>Jspalten6: </p> <hr /> <div>[[Category:Core]]<br /> This page lists all the things the organization must do toward the end of the spring and during the summer in order to prepare for the upcoming school year.&amp;nbsp;<br /> <br /> For useful Georgia Tech contacts who can help you do some of these things, see [[People_To_Know|People To Know]].<br /> <br /> == Vice President ==<br /> <br /> === Shop Access ===<br /> Shop keys should be retrieved and redistributed on a semesterly basis.<br /> <br /> Buzzcard access should be managed by the following criteria:<br /> <br /> Access to external SCC doors should be provided to all dues-paying members.<br /> <br /> Access to the common machining area and RoboJackets shop should be provided to all Core members, I.E., access should be given to members as soon as their names are added to the Core contact sheet, after attending their first Core meeting.<br /> <br /> To ensure these access groups are properly maintained, access should be revoked on a yearly basis, ideally close to dues deadline.<br /> <br /> == Secretary ==<br /> <br /> -Should help manage events, book classrooms and space for events, take meeting minutes, organize club documents, etc.<br /> <br /> <br /> <br /> == Public Relations Chair ==<br /> <br /> === Materials ===<br /> <br /> These need to be maintained and updated every year. They should always have our website, the Presidents contact info and the PR contact info on it.<br /> <br /> ===== Website and Gallery =====<br /> <br /> Make certain all officers and team leaders both have the necessary access and know how to post to the website. Also maker sure people who need to be able to post the gallery both know how to and have access as well. In addition to accessibility, keep them fresh, updated and alive.<br /> <br /> ===== Mechanical Engineering Brochure =====<br /> <br /> This is a brochure that the ME department uses. They use this for one whole year and it is given out to prospective students, new students, possible sponsors (either to us or ME), visitors, and interested parties. This will also be given out by us at many events and should offer a good overview of who we are and what we did last year. To update this, talk to Rona Ginsberg and update the other things that are handed out that talk about us.<br /> <br /> ===== Intro Event Hand Out =====<br /> <br /> Something about the size of a post card (maybe bigger). It should have our intro meeting time, date, location, logos of each event, the location of the SCC, and a short about us.<br /> <br /> ===== Business Cards =====<br /> <br /> Should have the contact info for the Pres, V Pres, website, and for your self since you are the contact for all thing media related.<br /> <br /> ===== List of Leaders and Contact Info =====<br /> <br /> Once the new officers and if necessary new team leaders have been decided, you need to update the list of Leaders and Team Leaders. This list should have both the cell number and email address of each team leader and officer. This is needed by Sterling Skinner (man who is in charge of the SCC) and it needs to be posted in the electrical room.<br /> <br /> ===== Shirts =====<br /> <br /> Inventory all of the shirts and find out how many of each type and size. Figure out how many we need of each and get a quote.<br /> <br /> === Events ===<br /> <br /> There are two important events that always happen and are a good source for new members. Also find out what else is going on around campus there will be more check with RIM and ME. Also look for department hosted socials to kick off the new school year these are great place to have a table and promote the RoboJackets. In addition, many schools have locations where you can put up a poster or some brochures.<br /> <br /> ===== FASET =====<br /> <br /> This is the freshman student orientation. There are six events and this is by far one of the best ways to meet new and incoming students.<br /> <br /> #In April the FASET application needs to be filled out and turned in<br /> #RoboJackets Flyers<br /> #Laptops for collecting emails<br /> #Display<br /> <br /> See [[HOWTO:_FASET]] for details<br /> <br /> ===== Grad Expo =====<br /> <br /> This is for incoming grad students and happens only once in August.<br /> <br /> *1) In May / June the application needs to be filled out and turned in.<br /> *2) Handouts for Intro meeting (see intro meeting for more)<br /> *3) Brochure from ME dept<br /> *4) Display<br /> <br /> If funding allows try to have a giveaway (ie. a RJ T-shirt NOT POLO's)<br /> <br /> ===== Involvement Fair =====<br /> <br /> Usually held on Skiles Walkway during either first or second week of school in the middle of the day.<br /> <br /> *1) App Due end of July / beginning of Aug.<br /> *2) Handouts for Intro meeting (see intro meeting for more)<br /> *3) Brochure from ME dept<br /> *4) Display<br /> <br /> ===== Introductory Meeting =====<br /> <br /> This one you have to setup and plan. It is suggested that you have it in the student center ballroom (because new students will at least know where the student center is located). It should also be on either the second or third week of class and not on Friday. Booking the event will cost some cash though not a lot (less than $100). Before the intro meeting you should visit each school ME, AE, EE, CS, etc and try to get the to spam their list about our meeting (around the first week of school). Once booked, the student center contact for events will need to meet with you about 2 to 3 weeks before hand to verify and make sure you are getting what we need.<br /> <br /> You need at least<br /> <br /> *Powerpoint<br /> *Short video<br /> *Some robots<br /> *Pizza<br /> **Papa Johns offers a 30% discount for over 10 large pizzas or 7.99 a pie for over 10 larges<br /> <br /> ===== End-of-year Banquet =====<br /> <br /> Once a year the club host an annual banquet to showcase our teams' accomplishments for the year to faculty, staff and students who are involved with RoboJackets. This event generally is centered around a presentation that is given by the officers and team leaders covering the club as a whole and each team. Food is also served in conjunction with the event.<br /> <br /> You need at least:<br /> <br /> *Updated Powerpoint and Video<br /> *Some Robots<br /> *Food<br /> *Event Space<br /> <br /> [[RJBanquet|More information about the banquet]]<br /> <br /> ===== Other Events =====<br /> <br /> Look for things like departmental socials and other events. You should try and find out about these in advance of their announcement inorder to have enough time to prepare. So talk to the people above in the People To Know section in the summer.<br /> <br /> You need<br /> <br /> *Display<br /> *Brochure<br /> *Robots<br /> <br /> ===== FIRST Kickoff =====<br /> <br /> *[[FIRSTKickoff|Kickoff Information]]<br /> <br /> ===== FIRST Peachtree Regional =====<br /> <br /> You need<br /> <br /> *Display<br /> *Brochure<br /> <br /> == Tool / Shop Master ==<br /> <br /> === Machines ===<br /> <br /> ==== Craftsman Bandsaw ====<br /> <br /> ==== Ryobi Drill Press ====<br /> <br /> ==== [[MIG_Pak_10_Welder|MIG_Pak_10_Welder]] ====<br /> <br /> == Technology and Computer Related ==<br /> <br /> Each year, the IT committee should complete the following tasks<br /> *Dust shop computers<br /> *Wipe down monitors, keyboards, and mice<br /> *Evaluate any hardware needing replacement<br /> *Update the standard RoboJackets Windows Image<br /> *Submit a budget proposal like project teams<br /> <br /> See the RoboJackets IT Docs on GT github for more info</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16905 2018-08-10T01:23:20Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.1.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on desired changes and improvements in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements in approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> ==== Example ====<br /> Improve sustainability&lt;sup&gt;1&lt;/sup&gt; and accountability&lt;sup&gt;2&lt;/sup&gt; in RoboJackets, and foster collaboration&lt;sup&gt;3&lt;/sup&gt; with knowledgeable entities&lt;sup&gt;4&lt;/sup&gt;. <br /> <br /> #Maintaining or improving management, technical, and human resources<br /> #Understanding of expectations and ownership of one’s actions<br /> #Exchanging of organizational and technical knowledge<br /> #External organizations and internal membership<br /> <br /> <br /> ==== Subteam Objective Statement ====<br /> <br /> From there, a subteam objective statement should be defined. A subteam objective statement is an objectives statement on a subteam level. Each subteam objective statement should support the overall goals of the objectives statement. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year, and corresponding milestones. Subteam objectives do not have to be based solely on the objective statement, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of tasks required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. <br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16904 2018-08-10T01:00:03Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.1.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on desired changes and improvements in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements in approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> ==== Example ====<br /> Improve sustainability&lt;sup&gt;1&lt;/sup&gt; and accountability&lt;sup&gt;2&lt;/sup&gt; in RoboJackets, and foster collaboration&lt;sup&gt;3&lt;/sup&gt; with knowledgeable entities&lt;sup&gt;4&lt;/sup&gt;. <br /> <br /> #Maintaining or improving management, technical, and human resources<br /> #Understanding of expectations and ownership of one’s actions<br /> #Exchanging of organizational and technical knowledge<br /> #External organizations and internal membership<br /> <br /> <br /> ==== Subteam Objective Statement ====<br /> <br /> From there, a subteam objective statement should be defined. A subteam objective statement is an objectives statement on a subteam level. Each subteam objective statement should support the overall goals of the objectives statement. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year, and corresponding milestones. Subteam objectives do not have to be based solely off of the objective statement, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of tasks required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. <br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16903 2018-08-10T00:57:19Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.1.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on desired changes in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but desired improvements in approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> ==== Example ====<br /> Improve sustainability&lt;sup&gt;1&lt;/sup&gt; and accountability&lt;sup&gt;2&lt;/sup&gt; in RoboJackets, and foster collaboration&lt;sup&gt;3&lt;/sup&gt; with knowledgeable entities&lt;sup&gt;4&lt;/sup&gt;. <br /> <br /> #Maintaining or improving management, technical, and human resources<br /> #Understanding of expectations and ownership of one’s actions<br /> #Exchanging of organizational and technical knowledge<br /> #External organizations and internal membership<br /> <br /> <br /> ==== Subteam Objective Statement ====<br /> <br /> From there, a subteam objective statement should be defined. A subteam objective statement is an objectives statement on a subteam level. Each subteam objective statement should support the overall goals of the objectives statement. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year, and corresponding milestones. Subteam objectives do not have to be based solely off of the objective statement, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of tasks required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. <br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16902 2018-08-10T00:19:05Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.1.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on changes in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but how the approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> The objectives statement should be focused on desired outcomes, not the methods which lead to a said outcomes. <br /> <br /> ==== Example ====<br /> Improve sustainability&lt;sup&gt;1&lt;/sup&gt; and accountability&lt;sup&gt;2&lt;/sup&gt; in RoboJackets, and foster collaboration&lt;sup&gt;3&lt;/sup&gt; with knowledgeable entities&lt;sup&gt;4&lt;/sup&gt;. <br /> <br /> #Maintaining or improving management, technical, and human resources<br /> #Understanding of expectations and ownership of one’s actions<br /> #Exchanging of organizational and technical knowledge<br /> #External organizations and internal membership<br /> <br /> <br /> ==== Subteam Objective Statement ====<br /> <br /> From there, a subteam objective statement should be defined. A subteam objective statement is an objectives statement on a subteam level. Each subteam objective statement should support the overall goals of the objectives statement. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year, and corresponding milestones. Subteam objectives do not have to be based solely off of the objective statement, but should come from similar motivation. <br /> <br /> Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of tasks required to successfully complete the objectives defined by the subteam objective statement. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week level. <br /> <br /> Tasks are the first time where implementation should enter a proposal. <br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=16897 2018-08-06T23:31:24Z

<p>Jspalten6: </p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which obstacles which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> Additionally, a liberal interpretation of &quot;act[ion] on behalf of the President in the even of his/her absence&quot; involves accepting direct delegation of Presidential duties from the President. Unfortunately, rarely do Presidents recognize or remember this particular privilege, and, therefore, Vice Presidents should be obstinate and observant in relieving the President of tasks.<br /> <br /> === Presidential Duties in the Absence of the President ===<br /> <br /> See [[President]]<br /> <br /> === Project Management ===<br /> There is no one way to manage a project, but good project management strategies have a few things in common:<br /> <br /> * Measurable, achievable goals with accountable people supporting them<br /> <br /> * Healthy forethought around objectives<br /> <br /> * Flexibility in the face of challenges<br /> <br /> The job of the Vice President is to ensure Project Managers are making their plans and managing their projects according to good project management practices.<br /> <br /> The Vice President is involved with the President and Treasurer in reviewing and accepting [[Proposals | Project Proposals]].<br /> <br /> == Information on Common Tasks ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list. It is recommended to do this at least five calendar days prior to the Core Meeting to allow ample time for leaders to fill in their sections with their reports, and to allow those who wish to bring important business to the attention of officers to do so within their reports.<br /> <br /> One perennial section of a Vice President's report in Core Agendas is the Recognitions section, into which any Core member may submit a name of a member and a reason for submitting them to have their name and accomplishment read. Often this is reserved for tasks considered un-glamorous and annoying, and, by providing direct recognition and gratitude, may encourage others to volunteer for similar tasks in the future.<br /> <br /> === Key Management ===<br /> <br /> The Vice President is responsible for ensuring keys to the shop are distributed to members with need for keys and value added by possession of keys. <br /> The Vice President should make this call based on their understanding of project needs, and should confer with relevant parties as necessary.<br /> Generally, recovery of keys should occur on a semester basis to ensure keys are all accounted for. <br /> <br /> The Vice President is also responsible for ensuring the [[People with Keys]] page is up to date.<br /> <br /> === Shop Access ===<br /> <br /> Historically, the duty of ensuring members have proper access to the shop has fallen on a variety of individuals, but most recently it has come under the Vice Presidential domain, and fits neatly into the overarching goal of removing obstacles to project objectives.<br /> <br /> Generally, updated lists of GTIDs, names, and access levels should be sent to Dr. Cunefare by email.<br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=16896 2018-08-06T23:17:05Z

<p>Jspalten6: </p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which challenges which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> Additionally, a liberal interpretation of &quot;act[ion] on behalf of the President in the even of his/her absence&quot; involves accepting direct delegation of Presidential duties from the President. Unfortunately, rarely do Presidents recognize or remember this particular privilege, and, therefore, Vice Presidents should be obstinate and observant in relieving the President of tasks.<br /> <br /> === Pro Tempore Presidential Duties ===<br /> <br /> See [[President]]<br /> <br /> === Project Management ===<br /> There is no one way to manage a project, but good project management strategies have a few things in common:<br /> <br /> * Measurable, achievable goals with accountable people supporting them<br /> <br /> * Healthy amounts of forethought around objectives<br /> <br /> * Flexibility in the face of challenges<br /> <br /> == Information on Common Tasks ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list. It is recommended to do this at least five calendar days prior to the Core Meeting to allow ample time for leaders to fill in their sections with their reports, and to allow those who wish to bring important business to the attention of officers to do so within their reports.<br /> <br /> One perennial section of a Vice President's report in Core Agendas is the Recognitions section, into which any Core member may submit a name of a member and a reason for submitting them to have their name and accomplishment read. Often this is reserved for tasks considered un-glamorous and annoying, and, by providing direct recognition and gratitude, may encourage others to volunteer for similar tasks in the future.<br /> <br /> === Key Management ===<br /> <br /> The Vice President is responsible for ensuring <br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=16895 2018-08-06T23:10:41Z

<p>Jspalten6: </p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which challenges which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> Additionally, a liberal interpretation of &quot;act[ion] on behalf of the President in the even of his/her absence&quot; involves accepting direct delegation of Presidential duties from the President. Unfortunately, rarely do Presidents recognize or remember this particular privilege, and, therefore, Vice Presidents should be obstinate and observant in relieving the President of tasks.<br /> <br /> === Project Management ===<br /> There is no one way to manage a project, but good project management strategies have a few things in common:<br /> <br /> <br /> == Information on Common Tasks ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list. It is recommended to do this at least five calendar days prior to the Core Meeting to allow ample time for leaders to fill in their sections with their reports, and to allow those who wish to bring important business to the attention of officers to do so within their reports.<br /> <br /> One perennial section of a Vice President's report in Core Agendas is the Recognitions section, into which any Core member may submit a name of a member and a reason for submitting them to have their name and accomplishment read. Often this is reserved for tasks considered un-glamorous and annoying, and, by providing direct recognition and gratitude, may encourage others to volunteer for similar tasks in the future.<br /> <br /> === Key Management ===<br /> <br /> The Vice President is responsible for ensuring <br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Vice-President&diff=16894 2018-08-06T22:55:42Z

<p>Jspalten6: </p> <hr /> <div>== Overview ==<br /> A Vice President of RoboJackets is, in essence, a project manager of the holistic and far-reaching project that is RoboJackets. This entails ensuring the project continues to function as planned, as well as finding methods through which challenges which might hinder the project are removed and finding methods through which the project may be made more efficient or better supported in some fashion.<br /> <br /> == Ex Officio Duties ==<br /> According to the RoboJackets Constitution:<br /> &quot;The Vice President will be the junior executive officer and will act on the behalf of the President in the event of his/her absence. The Vice President will work with project managers to ensure projects are executed as planned, and assist in presidential duties.&quot; <br /> <br /> Those serving as the Vice President will often find the President not to be absent very often as a direct result of the temperament required of a President, and will, therefore, see fit to find themselves tasks to aid in improving the organization as a whole.<br /> <br /> == Information on Common Tasks ==<br /> <br /> === Preparation and Distribution of Core Agendas ===<br /> Vice President has historically been the Core officer to prepare and send Core Meeting Agendas in the form of Google Docs out to the Core email list <br /> <br /> [[Category:Leadership Positions]][[Category:Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16830 2018-07-26T01:38:34Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred. <br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.1.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on changes in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but how the approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> ==== Example ====<br /> Improve sustainability&lt;sup&gt;1&lt;/sup&gt; and accountability&lt;sup&gt;2&lt;/sup&gt; in RoboJackets, and foster collaboration&lt;sup&gt;3&lt;/sup&gt; with knowledgeable entities&lt;sup&gt;4&lt;/sup&gt;. <br /> <br /> #Maintaining or improving management, technical, and human resources<br /> #Understanding of expectations and ownership of one’s actions<br /> #Exchanging of organizational and technical knowledge<br /> #External organizations and internal membership<br /> <br /> <br /> ==== Subteam Objectives ====<br /> <br /> From there, subteam objectives should be defined. A subteam objective is an objectives statement on a subteam level. Each subteam objective should support the overall goals of the objectives statement. Subteam objectives should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year, and corresponding milestones. Subteam objectives do not have to be based solely off of the objective statement, but should come from similar motivation. <br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of tasks required to successfully complete its associated subteam objective. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. <br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone. <br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Goals For Next Year ===<br /> <br /> Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later. <br /> <br /> ==== Bad Examples: ====<br /> <br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> <br /> ==== Good Examples: ====<br /> <br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Vision Characteristics ===<br /> <br /> Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking. <br /> <br /> ==== Examples: ====<br /> <br /> #&quot;Increasing visibility of what leadership does&quot; - has the right time scale and does not get into implementation specifics.<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == Changes ==<br /> <br /> Changes can be made to any master schedule milestone, pending Vice President approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed.<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.<br /> <br /> === Authority ===<br /> <br /> The authority to approve or pull funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16655 2018-07-15T23:55:00Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.1.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on changes in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but how the approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> ==== Subteam Objectives ====<br /> <br /> From there, subteam objectives, hereafter referred to as subteam objectives, ideally as bullet points, should be defined. Each subjective should support the overall goals of the objectives statement. Objectives should have a clear scope, and a set of actions that need to be taken to successfully complete the subteam objectives in the coming year.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subjectives become tasks. A task refers to the set of tasks required to successfully complete its associated subjective. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement.<br /> <br /> === Long Term Objectives ===<br /> <br /> The plan should encompass goals for each year in the next three. Unlike the previous section the goals here do not need to planned out but should be achievable within that time frame. The important question that should arise is how to ensure that a consistent overall vision is passed down between generations. You should be including the younger members on your team in these plans as likely you will not be around to see them completed. These goals can be anything from team trainings to advanced technical goals. If you are looking to spend large amounts of money in the future for technical tasks please include that. This gives time to develop sponsorships and gives you more money to buy expensive things in the future. In the past there is no carry over between years of goals, the intention is this section will resolve that. <br /> <br /> ==== Bad Examples: ====<br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> #&quot;Buy a really nice lidar&quot; - There is a complete failure to develop the need for this sensor. Give more explanation as to why it would be useful. Also this does not allow for developing sponsorships since it does not answer who could give us these lidars at a reduced price. A list of prospective companies would make this good.<br /> <br /> ==== Good Examples: ====<br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br /> <br /> At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == How funding works ==<br /> <br /> In the past project budgets were set at the beginning of the year with the entire budget for each team be allocated in one step. Since 2009 teams will have their budgets allocated in phases based on development the milestones they have specified. Not all milestones define a separate phase though but all phases will culminate with some milestone. It is '''required''' that teams at least have a '''design and and build phase''' with the milestone for the design phase being a successful design review. The design review shall be arranged by the team leader, the officers, and interested parties. Interested parties shall include all parties recognized by the officers and team leaders. Design reviews must happen at least at the initial design completion of a major project component (ie, drive system, main board, overall wiring plan, etc).<br /> <br /> === Milestones and Partial Completion ===<br /> <br /> Milestones for projects are the milestones and the final travel deadline. Completion of a milestone will be defined by the milestone itself. Partial completion of milestones will be defined by the officers and other interested parties with the input of the team leader. The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only.<br /> <br /> === Penalties ===<br /> <br /> Failure to meet a milestone will result in the team losing out on additional funding until they have either completed the milestone or made satisfactory progress towards the milestone. Satisfactory progress will be defined by the officers and other parties in with input from the team leader and will take into account external factors such as vendor related issues.<br /> <br /> === Changes ===<br /> <br /> Changes can be made to any deadline, pending officer approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests.<br /> <br /> === Changes vs. Partial Completion ===<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Change requests are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu, no additional stress is placed on the members by having to continue to work to meet a new deadline.<br /> <br /> === Authority ===<br /> <br /> The authority to approve funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=File:Objectives_Pyramid_Version_0.1.png&diff=16654 2018-07-15T23:54:38Z

<p>Jspalten6: </p> <hr /> <div></div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16653 2018-07-15T23:52:10Z

<p>Jspalten6: </p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on changes in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but how the approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> ==== Subteam Objectives ====<br /> <br /> From there, subteam objectives, hereafter referred to as subteam objectives, ideally as bullet points, should be defined. Each subjective should support the overall goals of the objectives statement. Objectives should have a clear scope, and a set of actions that need to be taken to successfully complete the subteam objectives in the coming year.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subjectives become tasks. A task refers to the set of tasks required to successfully complete its associated subjective. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement.<br /> <br /> === Long Term Objectives ===<br /> <br /> The plan should encompass goals for each year in the next three. Unlike the previous section the goals here do not need to planned out but should be achievable within that time frame. The important question that should arise is how to ensure that a consistent overall vision is passed down between generations. You should be including the younger members on your team in these plans as likely you will not be around to see them completed. These goals can be anything from team trainings to advanced technical goals. If you are looking to spend large amounts of money in the future for technical tasks please include that. This gives time to develop sponsorships and gives you more money to buy expensive things in the future. In the past there is no carry over between years of goals, the intention is this section will resolve that. <br /> <br /> ==== Bad Examples: ====<br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> #&quot;Buy a really nice lidar&quot; - There is a complete failure to develop the need for this sensor. Give more explanation as to why it would be useful. Also this does not allow for developing sponsorships since it does not answer who could give us these lidars at a reduced price. A list of prospective companies would make this good.<br /> <br /> ==== Good Examples: ====<br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br /> <br /> At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == How funding works ==<br /> <br /> In the past project budgets were set at the beginning of the year with the entire budget for each team be allocated in one step. Since 2009 teams will have their budgets allocated in phases based on development the milestones they have specified. Not all milestones define a separate phase though but all phases will culminate with some milestone. It is '''required''' that teams at least have a '''design and and build phase''' with the milestone for the design phase being a successful design review. The design review shall be arranged by the team leader, the officers, and interested parties. Interested parties shall include all parties recognized by the officers and team leaders. Design reviews must happen at least at the initial design completion of a major project component (ie, drive system, main board, overall wiring plan, etc).<br /> <br /> === Milestones and Partial Completion ===<br /> <br /> Milestones for projects are the milestones and the final travel deadline. Completion of a milestone will be defined by the milestone itself. Partial completion of milestones will be defined by the officers and other interested parties with the input of the team leader. The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only.<br /> <br /> === Penalties ===<br /> <br /> Failure to meet a milestone will result in the team losing out on additional funding until they have either completed the milestone or made satisfactory progress towards the milestone. Satisfactory progress will be defined by the officers and other parties in with input from the team leader and will take into account external factors such as vendor related issues.<br /> <br /> === Changes ===<br /> <br /> Changes can be made to any deadline, pending officer approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests.<br /> <br /> === Changes vs. Partial Completion ===<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Change requests are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu, no additional stress is placed on the members by having to continue to work to meet a new deadline.<br /> <br /> === Authority ===<br /> <br /> The authority to approve funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16652 2018-07-15T23:36:47Z

<p>Jspalten6: Added image of objectives pyramid</p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below. [[File:Objectives_Pyramid_Version_0.png | thumb | right | 600px | The Objectives Pyramid]]<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on changes in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but how the approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> ==== Subjectives (Subteam Objectives) ====<br /> <br /> From there, subteam objectives, hereafter referred to as subjectives, ideally as bullet points, should be defined. Each subjective should support the overall goals of the objectives statement. Objectives should have a clear scope, and a set of actions that need to be taken to successfully complete the subjectives in the coming year.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subjectives become tasks. A task refers to the set of tasks required to successfully complete its associated subjective. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement.<br /> <br /> === Long Term Objectives ===<br /> <br /> The plan should encompass goals for each year in the next three. Unlike the previous section the goals here do not need to planned out but should be achievable within that time frame. The important question that should arise is how to ensure that a consistent overall vision is passed down between generations. You should be including the younger members on your team in these plans as likely you will not be around to see them completed. These goals can be anything from team trainings to advanced technical goals. If you are looking to spend large amounts of money in the future for technical tasks please include that. This gives time to develop sponsorships and gives you more money to buy expensive things in the future. In the past there is no carry over between years of goals, the intention is this section will resolve that. <br /> <br /> ==== Bad Examples: ====<br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> #&quot;Buy a really nice lidar&quot; - There is a complete failure to develop the need for this sensor. Give more explanation as to why it would be useful. Also this does not allow for developing sponsorships since it does not answer who could give us these lidars at a reduced price. A list of prospective companies would make this good.<br /> <br /> ==== Good Examples: ====<br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br /> <br /> At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == How funding works ==<br /> <br /> In the past project budgets were set at the beginning of the year with the entire budget for each team be allocated in one step. Since 2009 teams will have their budgets allocated in phases based on development the milestones they have specified. Not all milestones define a separate phase though but all phases will culminate with some milestone. It is '''required''' that teams at least have a '''design and and build phase''' with the milestone for the design phase being a successful design review. The design review shall be arranged by the team leader, the officers, and interested parties. Interested parties shall include all parties recognized by the officers and team leaders. Design reviews must happen at least at the initial design completion of a major project component (ie, drive system, main board, overall wiring plan, etc).<br /> <br /> === Milestones and Partial Completion ===<br /> <br /> Milestones for projects are the milestones and the final travel deadline. Completion of a milestone will be defined by the milestone itself. Partial completion of milestones will be defined by the officers and other interested parties with the input of the team leader. The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only.<br /> <br /> === Penalties ===<br /> <br /> Failure to meet a milestone will result in the team losing out on additional funding until they have either completed the milestone or made satisfactory progress towards the milestone. Satisfactory progress will be defined by the officers and other parties in with input from the team leader and will take into account external factors such as vendor related issues.<br /> <br /> === Changes ===<br /> <br /> Changes can be made to any deadline, pending officer approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests.<br /> <br /> === Changes vs. Partial Completion ===<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Change requests are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu, no additional stress is placed on the members by having to continue to work to meet a new deadline.<br /> <br /> === Authority ===<br /> <br /> The authority to approve funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=File:Objectives_Pyramid_Version_0.png&diff=16651 2018-07-15T23:33:16Z

<p>Jspalten6: The objectives pyramid shows the structure of objective statements, subjectives, and tasks as mechanisms for accomplishing goals in a project.</p> <hr /> <div>The objectives pyramid shows the structure of objective statements, subjectives, and tasks as mechanisms for accomplishing goals in a project.</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16650 2018-07-15T23:30:13Z

<p>Jspalten6: Added subsection headers on components of the objectives pyramid</p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below.<br /> <br /> ==== Objectives Statement ====<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on changes in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but how the approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> ==== Subjectives (Subteam Objectives) ====<br /> <br /> From there, subteam objectives, hereafter referred to as subjectives, ideally as bullet points, should be defined. Each subjective should support the overall goals of the objectives statement. Objectives should have a clear scope, and a set of actions that need to be taken to successfully complete the subjectives in the coming year.<br /> <br /> ==== Tasks ====<br /> <br /> The actions that need to be taken to complete the subjectives become tasks. A task refers to the set of tasks required to successfully complete its associated subjective. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement.<br /> <br /> === Long Term Objectives ===<br /> <br /> The plan should encompass goals for each year in the next three. Unlike the previous section the goals here do not need to planned out but should be achievable within that time frame. The important question that should arise is how to ensure that a consistent overall vision is passed down between generations. You should be including the younger members on your team in these plans as likely you will not be around to see them completed. These goals can be anything from team trainings to advanced technical goals. If you are looking to spend large amounts of money in the future for technical tasks please include that. This gives time to develop sponsorships and gives you more money to buy expensive things in the future. In the past there is no carry over between years of goals, the intention is this section will resolve that. <br /> <br /> ==== Bad Examples: ====<br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> #&quot;Buy a really nice lidar&quot; - There is a complete failure to develop the need for this sensor. Give more explanation as to why it would be useful. Also this does not allow for developing sponsorships since it does not answer who could give us these lidars at a reduced price. A list of prospective companies would make this good.<br /> <br /> ==== Good Examples: ====<br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br /> <br /> At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == How funding works ==<br /> <br /> In the past project budgets were set at the beginning of the year with the entire budget for each team be allocated in one step. Since 2009 teams will have their budgets allocated in phases based on development the milestones they have specified. Not all milestones define a separate phase though but all phases will culminate with some milestone. It is '''required''' that teams at least have a '''design and and build phase''' with the milestone for the design phase being a successful design review. The design review shall be arranged by the team leader, the officers, and interested parties. Interested parties shall include all parties recognized by the officers and team leaders. Design reviews must happen at least at the initial design completion of a major project component (ie, drive system, main board, overall wiring plan, etc).<br /> <br /> === Milestones and Partial Completion ===<br /> <br /> Milestones for projects are the milestones and the final travel deadline. Completion of a milestone will be defined by the milestone itself. Partial completion of milestones will be defined by the officers and other interested parties with the input of the team leader. The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only.<br /> <br /> === Penalties ===<br /> <br /> Failure to meet a milestone will result in the team losing out on additional funding until they have either completed the milestone or made satisfactory progress towards the milestone. Satisfactory progress will be defined by the officers and other parties in with input from the team leader and will take into account external factors such as vendor related issues.<br /> <br /> === Changes ===<br /> <br /> Changes can be made to any deadline, pending officer approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests.<br /> <br /> === Changes vs. Partial Completion ===<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Change requests are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu, no additional stress is placed on the members by having to continue to work to meet a new deadline.<br /> <br /> === Authority ===<br /> <br /> The authority to approve funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=Proposals&diff=16649 2018-07-15T23:27:51Z

<p>Jspalten6: Updated Current Year Planning explanation to incorporate objectives pyramid</p> <hr /> <div>Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.<br /> <br /> A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.<br /> <br /> = Proposal Contents =<br /> <br /> == Prior Results ==<br /> <br /> A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to the proposal.<br /> <br /> == Project Description ==<br /> <br /> === Year Long Objectives ===<br /> <br /> To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below.<br /> <br /> To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on changes in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but how the approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.<br /> <br /> From there, subteam objectives, hereafter referred to as subjectives, ideally as bullet points, should be defined. Each subjective should support the overall goals of the objectives statement. Objectives should have a clear scope, and a set of actions that need to be taken to successfully complete the subjectives in the coming year.<br /> The actions that need to be taken to complete the subjectives become tasks. A task refers to the set of tasks required to successfully complete its associated subjective. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement.<br /> <br /> === Long Term Objectives ===<br /> <br /> The plan should encompass goals for each year in the next three. Unlike the previous section the goals here do not need to planned out but should be achievable within that time frame. The important question that should arise is how to ensure that a consistent overall vision is passed down between generations. You should be including the younger members on your team in these plans as likely you will not be around to see them completed. These goals can be anything from team trainings to advanced technical goals. If you are looking to spend large amounts of money in the future for technical tasks please include that. This gives time to develop sponsorships and gives you more money to buy expensive things in the future. In the past there is no carry over between years of goals, the intention is this section will resolve that. <br /> <br /> ==== Bad Examples: ====<br /> #&quot;Improve team specific training&quot; - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.<br /> #&quot;Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots&quot; - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.<br /> #&quot;Buy a really nice lidar&quot; - There is a complete failure to develop the need for this sensor. Give more explanation as to why it would be useful. Also this does not allow for developing sponsorships since it does not answer who could give us these lidars at a reduced price. A list of prospective companies would make this good.<br /> <br /> ==== Good Examples: ====<br /> #&quot;Establish new member training for each sub-team&quot; - A good training program can take years of tweaking to become effective. <br /> #&quot;Implement XX to improve motion control&quot; - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.<br /> <br /> === Milestones ===<br /> <br /> The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.<br /> <br /> Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.<br /> <br /> At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition<br /> <br /> ==== Milestones Example ====<br /> <br /> *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task<br /> *After fall break - Demo at least 2 new prototype drive-trains<br /> *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,<br /> *Feb 1st - Demo new manipulator using individual joint control<br /> *March 1st - Extended range driving<br /> *Spring Break - Demo some of the competition tasks using the manipulator<br /> *April 30th - Finalize travel plans, demo robot performing some competition objectives<br /> <br /> === Resources ===<br /> <br /> Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.<br /> <br /> ==== Monetary ====<br /> <br /> This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.<br /> <br /> ==== Personnel ====<br /> <br /> Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads, skill sets roughly means interest.<br /> <br /> ==== Capital Outlays/Tooling ====<br /> <br /> While our shop and SCC provide an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.<br /> <br /> ==== Travel/Registration ====<br /> <br /> In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels, <br /> <br /> See [[Budgeting for Travel]] and [[Travel Policy]] for information on what RoboJackets will pay for and how to accurately plan expenses.<br /> <br /> In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. It should be based on a projected number of attendees.<br /> <br /> === Schedule ===<br /> <br /> The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one.<br /> <br /> There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here: http://live.gnome.org/Planner)<br /> <br /> === New Member Projects ===<br /> <br /> How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.<br /> <br /> ==== Bad Examples: ====<br /> #&quot;Fix computer vision&quot; - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good. <br /> #&quot;Manufacture part X to be used on the robot&quot; - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible. <br /> <br /> ==== Good Examples: ====<br /> #&quot;Implement GUI to display robot state&quot; - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.<br /> #&quot;Use machine learning to detect XX&quot; - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.<br /> <br /> <br /> === Budget ===<br /> <br /> The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.<br /> <br /> === Supplemental Documentation ===<br /> <br /> Any documentation that the team leader feels is required in addition to the above.<br /> <br /> == How funding works ==<br /> <br /> In the past project budgets were set at the beginning of the year with the entire budget for each team be allocated in one step. Since 2009 teams will have their budgets allocated in phases based on development the milestones they have specified. Not all milestones define a separate phase though but all phases will culminate with some milestone. It is '''required''' that teams at least have a '''design and and build phase''' with the milestone for the design phase being a successful design review. The design review shall be arranged by the team leader, the officers, and interested parties. Interested parties shall include all parties recognized by the officers and team leaders. Design reviews must happen at least at the initial design completion of a major project component (ie, drive system, main board, overall wiring plan, etc).<br /> <br /> === Milestones and Partial Completion ===<br /> <br /> Milestones for projects are the milestones and the final travel deadline. Completion of a milestone will be defined by the milestone itself. Partial completion of milestones will be defined by the officers and other interested parties with the input of the team leader. The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only.<br /> <br /> === Penalties ===<br /> <br /> Failure to meet a milestone will result in the team losing out on additional funding until they have either completed the milestone or made satisfactory progress towards the milestone. Satisfactory progress will be defined by the officers and other parties in with input from the team leader and will take into account external factors such as vendor related issues.<br /> <br /> === Changes ===<br /> <br /> Changes can be made to any deadline, pending officer approval. The criteria for approval are:<br /> <br /> *Time until deadline in question<br /> *Progress made<br /> *External factors<br /> <br /> Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests.<br /> <br /> === Changes vs. Partial Completion ===<br /> <br /> It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Change requests are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu, no additional stress is placed on the members by having to continue to work to meet a new deadline.<br /> <br /> === Authority ===<br /> <br /> The authority to approve funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.<br /> <br /> In general the officers can only ''enforce'' the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:<br /> <br /> #if appointed by a team leader,<br /> #if there are no members to take lead of project,<br /> #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.<br /> <br /> [[Category: Core]]</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=16258 2018-05-25T16:08:12Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 4<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 5<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 7<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 8<br /> |Collin Avidano<br /> |-<br /> | 3SB6: 9<br /> | Ryan Waldheim<br /> |-<br /> | 3SB6:12<br /> | John Carnahan<br /> |-<br /> | 3SB6:14<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:15<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> |Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | Cory Stine<br /> |-<br /> | 3SB6:21<br /> | Jeremy Feltracco<br /> |-<br /> | 3SB6:22<br /> | Hank Hellstrom<br /> |-<br /> | 3SB6:23<br /> | Carrie Li<br /> |-<br /> | 3SB6:24<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> |''Unassigned''<br /> |-<br /> | 3SB6:31<br /> |Daniil Budanov<br /> |-<br /> |3SB6:33<br /> |''Unassigned''<br /> |-<br /> |3SB6:34<br /> |Jason Gibson<br /> |-<br /> |3SB6:36<br /> |Varun Madabushi<br /> |-<br /> |3SB6:38<br /> |''Unassigned''<br /> |-<br /> |3SB6:39<br /> |''Unassigned''<br /> |-<br /> |3SB6: 40<br /> |''Unassigned''<br /> |-<br /> |3SB6: 41<br /> |Noah Daugherty<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6: 45<br /> |''Unassigned''<br /> |}</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=16222 2018-05-15T00:38:51Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 4<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 5<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 7<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 8<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 9<br /> | Ryan Waldheim<br /> |-<br /> | 3SB6:12<br /> | John Carnahan<br /> |-<br /> | 3SB6:14<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:15<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> |Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:21<br /> | Jeremy Feltracco<br /> |-<br /> | 3SB6:22<br /> |''Unassigned''<br /> |-<br /> | 3SB6:23<br /> | Carrie Li<br /> |-<br /> | 3SB6:24<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:27<br /> | Juan Almagro<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> |''Unassigned''<br /> |-<br /> | 3SB6:31<br /> |Daniil Budanov<br /> |-<br /> |3SB6:33<br /> |''Unassigned''<br /> |-<br /> |3SB6:34<br /> |Jason Gibson<br /> |-<br /> |3SB6:36<br /> |Varun Madabushi<br /> |-<br /> |3SB6:38<br /> |''Unassigned''<br /> |-<br /> |3SB6:39<br /> |''Unassigned''<br /> |-<br /> |3SB6: 40<br /> |''Unassigned''<br /> |-<br /> |3SB6: 41<br /> |Noah Daugherty<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6: 45<br /> |Jonathan Spalten<br /> |}</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=16186 2018-05-05T22:30:53Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 4<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 5<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 7<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 8<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 9<br /> | Ryan Waldheim<br /> |-<br /> | 3SB6:12<br /> | John Carnahan<br /> |-<br /> | 3SB6:14<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:15<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> |Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:21<br /> | Jeremy Feltracco<br /> |-<br /> | 3SB6:22<br /> |''Unassigned''<br /> |-<br /> | 3SB6:23<br /> | Carrie Li<br /> |-<br /> | 3SB6:24<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:27<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> |''Unassigned''<br /> |-<br /> | 3SB6:31<br /> |Daniil Budanov<br /> |-<br /> |3SB6:33<br /> |''Unassigned''<br /> |-<br /> |3SB6:34<br /> |Jason Gibson<br /> |-<br /> |3SB6:36<br /> |Varun Madabushi<br /> |-<br /> |3SB6:38<br /> |''Unassigned''<br /> |-<br /> |3SB6:39<br /> |''Unassigned''<br /> |-<br /> |3SB6: 40<br /> |''Unassigned''<br /> |-<br /> |3SB6: 41<br /> |Noah Daugherty<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6: 45<br /> |Jonathan Spalten<br /> |}</div>

Jspalten6 https://wiki.robojackets.org/index.php?title=People_with_Keys&diff=16185 2018-05-05T14:41:01Z

<p>Jspalten6: </p> <hr /> <div>'''These people have keys to the RoboJackets shop area. '''&lt;br/&gt;See [[Shop_Keys|Shop Keys]] for details on key assignments.<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |-<br /> ! Key Number<br /> ! Assigned To<br /> |-<br /> | 3SB6: 1<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 4<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 5<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 7<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 8<br /> |''Unassigned''<br /> |-<br /> | 3SB6: 9<br /> | Ryan Waldheim<br /> |-<br /> | 3SB6:12<br /> | John Carnahan<br /> |-<br /> | 3SB6:14<br /> | [[User:Snaeem|Sameer Naeem]]<br /> |-<br /> | 3SB6:15<br /> |Evan Peterson<br /> |-<br /> | 3SB6:18<br /> | Joshua Viszlai<br /> |-<br /> | 3SB6:19<br /> |Will Stuckey<br /> |-<br /> | 3SB6:20<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:21<br /> | Jeremy Feltracco<br /> |-<br /> | 3SB6:22<br /> |''Unassigned''<br /> |-<br /> | 3SB6:23<br /> | Carrie Li<br /> |-<br /> | 3SB6:24<br /> | ''Unassigned''<br /> |-<br /> | 3SB6:27<br /> | Leo Medrano<br /> |-<br /> | 3SB6:28<br /> | Joseph Spall<br /> |-<br /> | 3SB6:29<br /> | [[User:Mbarulic|Matthew Barulic]]<br /> |-<br /> |3SB6:30<br /> |''Unassigned''<br /> |-<br /> | 3SB6:31<br /> |Daniil Budanov<br /> |-<br /> |3SB6:33<br /> |''Unassigned''<br /> |-<br /> |3SB6:34<br /> |Jason Gibson<br /> |-<br /> |3SB6:36<br /> |Varun Madabushi<br /> |-<br /> |3SB6:38<br /> |''Unassigned''<br /> |-<br /> |3SB6:39<br /> |''Unassigned''<br /> |-<br /> |3SB6: 40<br /> |''Unassigned''<br /> |-<br /> |3SB6: 41<br /> |Noah Daugherty<br /> |-<br /> |3SB6:43<br /> |Young Won<br /> |-<br /> |3SB6:44<br /> |Matthew Woodward<br /> |-<br /> |3SB6: 45<br /> |Jonathan Spalten<br /> |}</div>

Jspalten6