SYSCOM Bulletin Board #0101
Written by : Jas_nRuski
Last Edited: 06/09/21
Introduction
This document is to inform a developer of their regulations and terms including but not limited to responsibilities, payment information, and DMCA notices.
All aspects of the game/bases, under the group of United States Armed Forces and all its affiliation, are protected under the United States Digital Millennium Copyright Act. The physical game, including but not limited to models, structures, equipment, are properties of Caviahr and the Navy Development Team.
ALL DEVELOPERS MUST AGREE TO AND ABIDE BY ALL CODES IN THE DOCUMENT IN ORDER TO BE A MEMBER OF THE DEVELOPMENT TEAM.
TABLE OF CONTENTS
[CHAPTER ONE: DUTIES AND CHAIN OF COMMAND]
[CHAPTER TWO: ASSET MANAGEMENT]
-
Section A: Submission and Ownership
-
Section B: Asset Withdrawal
-
Section C: Third-Party Assets
-
Section D: Cross-Branch Asset Sharing
-
Section E: Unlawfully Acquired Assets
[CHAPTER THREE: CODE OF CONDUCT]
-
Section A: General Ethics
-
Section B: Information Confidentiality
-
Section C: Development Ethics
-
Section D: Developmental Affiliation
[CONCLUSION]
CHAPTER ONE: DUTIES AND CHAIN OF COMMAND
Section A: Duties and Responsibilities
Section B: Chain of Command
The Navy System Command’s chain of command is categorized in CLASSES, with Class A being the highest, and class C being the lowest.
Class A: Development Administration
Class B: Vice-Development Administration
Class C: Developers
CHAPTER TWO: ASSET MANAGEMENT
Section A: Submission and Ownership
Example 1:
A developer imports a helicopter for an aircraft division upon request/order of the administration, Caviahr’s USM owns all rights to that import.
Example 2:
A company sells Caviahr’s USM a custom imported vehicle. Caviahr’s USM owns all rights to a copy of that file.
Section B: Asset Withdrawal
Section C: Third-Party Assets
Section D: Cross-Branch Asset Sharing
Assets that are used in one branch are strictly prohibited from being shared with another branch inside/outside of their respective branch without prior written or verbal approval from the head developer.
Section E: Unlawfully Acquired Assets
Unlawfully acquired assets are defined as any assets that are acquired unrightfully. This can include leaked models/games/maps.
If any of these assets are found and confirmed, the submission developer in question will face consequences depending on the seriousness. The asset will be removed within 24 hours.
Section F: Contracted Asset
Some of the assets that developers make may be under the name of a company/organization they work for. If so, the contract must be submitted BEFORE the submission of the asset (implementing it into the game). Otherwise, the administration will automatically assume rights unless otherwise stated.
The vast majority of the assets within games owned by Caviahr’s United States Military (and all branches) are considered Intellectual-Property of Caviahr’s United States Military and are therefore copyrighted by the Copyright Law of the United States. THE DEVELOPMENT ADMINISTRATION RESERVES THE RIGHT TO FILE A DMCA COMPLAINT IF THE ASSET IS SHARED/USED WITHOUT THE ADMINISTRATION’S PERMISSION. THERE MAY OR MAY NOT BE A WARNING.
CHAPTER THREE: CODE OF CONDUCT
Section A: General Ethics
All developers must show utter respect to one another at all times. There is no room for toxicity and disrespecting one another here.
Some minor “toxicity comments” will occur from time to time as a joke and not intended to be malicious.
All developers are expected to abide by the ROBLOX Terms of Service, Discord Terms of Service, ROBLOX Community Guidelines, any other developmental agreements that they are to abide by, all codes within Caviahr’s Uniform Code of Justice, and all codes stated in this document.
Section B: Information Confidentiality
Most of the information including but not limited to chat, files, images, links are required to remain classified within the development. However, not all information is classified. The below list will list some of the information that can typically be released and some that are strictly not allowed to be released.
Info that is generally declassified:
- Asset showcases (!)
- Sneak peaks (!)
- Developer’s DMs (!)
- Status on bugs/requested suggestions and developer’s comment on said topics.
(!): It is highly not recommended to share these types of information or share with extreme caution or seek clarification from development administration prior to release.
Info that is generally CLASSIFIED:
- What our future plan is.
- Developer’s Payment and Status.
- Any internal conflicts.
Info that is STRICTLY CLASSIFIED:
- Scripts/source codes.
- How a code/part of the game functions.
- All asset files.
DEVELOPERS ARE ORDERED TO SEEK FOR CLARIFICATION SHOULD THEY BE UNABLE TO DETERMINE WHETHER A PIECE OF INFORMATION SHOULD BE RELEASED OR REMAIN UNDISCLOSED.
Section C: Development Ethics
DEADLINES
All developers will be assigned/asked to assign a deadline for each project they work on. That deadline should ALWAYS be followed and remain unchanged.
Generally speaking, a developer has anywhere between 24-128 hours for a small project, anywhere between 7 to 20 days for a medium-sized project, and no less than 45 days for a big project.
If a deadline has to be changed, a 48-hour prior notice is required.
PROFESSIONALISM
All developers are asked to remain professional while in public discussing developmental matters and within the team.
Constructive arguments and idea differentiates are permitted and all arguments pertaining to that are permitted. Developers should be aware of what’s acceptable and what’s not acceptable in those types of conversations.
If an event is scheduled ahead of time, the developers must make time for that event and always arrive on time/plan ahead.
All developers are asked to uphold their promises and agreements at all times. For example, if they promise to deliver a bug patch within 24 hours, the said bug should be fixed in under 24 hours and changes shall be published.
ABSENCE
We (development administration) respect developers having different personal life and schedules outside of ROBLOX, and a developer should not be punished for living on a different schedule.
A developer, if they need to leave for more than 72 hours, should always consult their respective supervisor 12-24 hours prior to the leave. If a developer is away for more than 20 days, they may be replaced by another developer and/or removed.
However, they still have to abide by their deadlines and work ethics.
We also understand that personal emergency can sometimes take place including but not limited to a last-minute schedule change, family emergency, health emergency, work call, etc. As stated, we ask you to do your best to keep these types of emergencies to a bare minimum.
A developer that is absent without leave will be removed from the development team.
HEADQUARTERS/DIVISION INTERNAL MATTERS
A DEVELOPER HAS NO GROUNDS OF SPEAKING ON ANY INTERNAL MATTERS UNLESS THEY HAVE THE PROPER AUTHORITY TO DO SO.
For example: A developer is not allowed to change the Uniform of the Day Guideline.A DEVELOPER IS NOT A PART OF THE BRANCH HEADQUARTER NOR ARE THEY A PART OF A DIVISIONAL/COMMAND HEADQUARTERS UNLESS THEY POSSESS THE PROPER RANK TO DO SO.
For example: A developer, who is divisionless, is not allowed to arrest a civilian.A DEVELOPER SHOULD NEVER INFLUENCE THEIR DECISION/ACTION BASED ON ANY DIVISIONAL/COMMAND/RANK ISSUES. SUCH ACTIONS ARE NOT TOLERATED AND WILL RESULT IN REMOVAL & BLACKLIST OF THE DEVELOPER.
For example: A developer, who holds a staff position in Carrier Air Wing 9, which is demoted and removed from that position, should not threaten to remove/remove any pieces of equipment that are issued to the division.
UNIFORMS/APPARELS
A developer should always present themselves in a professional manner and respect the regulation put in place by the respective branch head.
All developers, INCLUDING INTERNS, must be:
- Either wearing a development shirt & trousers, formal suits, or appropriate clothing such as a flannel shirt, 5.11 jacket, etc.
- Not wearing any body-packages.
- Not wearing any accessories.
- Have realistic/default faces on with no teeth showing.
Facial hairs and other head accessories are allowed to a certain extent while remaining realistic and professional.
If a developer has a paygrade, they are allowed to bear uniforms.
#### RANKS, PAYGRADES, BILLETS
A developer, who passes the intern stage, must forfeit their current rank, paygrade, and billets. They do NOT have to forfeit those during their internship process.
Section D: Developmental Affiliation
DEVELOPMENT COMMUNITIES
We respect developers that hold a moderation/management position in a public/private development community such as ACS, HiddenDevs, Polarstar, etc. We simply ask developers to refrain from using those positions as an advantage.
DEVELOPMENT ORGANIZATIONS/COMPANIES AND PRIVATE COMMISSIONERS
We respect developers that are a part of a development company/organization or simply just a private commissioned developer. However, we simply ask developers to refrain from using those positions as an advantage.
A developer, while working on an official project for the Department of Navy, is NOT allowed to put their work under the company’s name without written consent from Secretary of the Navy and Senior Enlisted Advisor to the Chairman.
CONCLUSION
By joining the Navy Development Team, a developer hereby agrees to all informational items above.
Signed:
Jas_nRuski, Head Developer