-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modify Staff FTE to go up to 2 #927
Comments
Proposed solution for use case 927 |
Proposed Element Format: Numeric should be 0.00<=2.00 (2 decimal places, not 2 digits) |
@gilbertcj6 @manndoris-CEPI See attached proposal with changes. The IDS presently has this element set at DECIMAL(5,4) which means it can have up to 4 digits after the decimal. So it could be 1.2500. The attached proposal change is Numeric - up to 4 decimal places so that it matches the IDS currently. With MI approval, CEDS will place in pending community approval. |
Pretty confident that will work Jackie, but will wait for CJ to chime in on it when she gets back tomorrow. |
Michigan definitely approves!
Thank you for giving me a chance to run it past our SMEs first. 🙂
~CJ
CJ Gilbert (she/her)
Longitudinal Data Analyst
***@***.******@***.***>
[cid:732c8f6d-5cbc-4a4f-b53a-72511274a59a]
Center for Educational Performance and Information (CEPI)
Michigan Department of Technology, Management & Budget (DTMB)
702 W. Kalamazoo St | Third Floor, Michigan Library and Historical Center | Lansing, MI 48915
[cid:c60d9776-dcfd-4899-97c7-95e8e136c71a]
Get personalized voter information on early voting and other topics at Michigan.gov/Vote<https://mvic.sos.state.mi.us/>
…________________________________
From: Doris Mann ***@***.***>
Sent: Tuesday, October 8, 2024 3:49 PM
To: CEDStandards/CEDS-Elements ***@***.***>
Cc: Gilbert, Christine (CEPI) ***@***.***>; Mention ***@***.***>
Subject: Re: [CEDStandards/CEDS-Elements] Modify Staff FTE to go up to 2 (Issue #927)
CAUTION: This is an External email. Please send suspicious emails to ***@***.***
Pretty confident that will work Jackie, but will wait for CJ to chime in on it when she gets back tomorrow.
—
Reply to this email directly, view it on GitHub<#927 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BIKBQDGCVOJ4D236FURTLXTZ2QZL7AVCNFSM6AAAAABPQHH2LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBQGY4TINBSGM>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
The attached |
Should we not be talking about a new data element for this purpose? The proposed use cases sound more like they would best be addressed with a new element such as 'Workload FTE' or 'Comparative FTE' that would not be restricted to values between 0.00 and 1.00 like a single assignment. This would avoid breaking changes anticipated in both up and downstream systems that rely on the value being currently restricted as is on a single assignment. Under the existing interpretation the total over all of an individual's assignments can still come out to be a value greater than 1.00, but a single assignment cannot by itself exceed the value 1.00. A new data element would also not necessarily need to be tied to an assignment, but could go wherever it needs to go (e.g. K12Staff -> Employment) to best fulfill the use case. |
Thank you for raising this concern. Any breaking change requires thoughtful consideration. This proposal corrects an assumption that was made during the original creation of this element -- that every state limits an assignment to a maximum of 1 FTE. This assumption is not true for Michigan. We do indeed have single assignments that exceed 1.00 FTE in our data collections -- these are not the sum of a variety of assignments but a single assignment where the person is working above one FTE for that assignment. Our proposed use case referenced a teaching example, but we also have this happening for a variety of other staffing positions including support staff, clerical, bus drivers, etc. While the idea of a 'Workload FTE' is an interesting idea that merits consideration, it would have a different definition than just "FTE" -- it would be the sum of a person's FTEs across all their assignments. As such, it does not solve Michigan's use case because it would combine FTE's from vastly different assignments with vastly different reporting requirements (such as a Special Education Teacher who is also a coach in the evenings). We need to be able to accurately record the FTE for a single assignment, even if that FTE is greater than one, so that we can accurate report that FTE to US ED. Modifying this element to allow values greater than 1 does not compel other states to collect data great than 1. They are still free to put in place constraints in their data collection process that will prevent the submission of values greater than 1. In most cases, I would hope that those constraints would be already in place, but if they are not in place, this would be the advance notice that they need to be added to the relevant system or application. If you believe this needs further discussion in a workgroup, please let us know. |
Thanks for the elaboration. Then the only other option to increasing the range like you are proposing would possibly be to represent FTEs > 1.00 as two assignments: a 1.00 assignment and a 0.20 (overflow) assignment. |
This is for capturing needs not currently supported by the CEDS model. Please do not send or share actual data as examples in this issue or in attachments.
Author(s): CJ Gilbert; Kristy Webber
Authoring Organization(s): State of Michigan/CEPI
Email address: [email protected]
Use Case Title: Modify Staff FTE to go up to 2
Use Case Description
Modify the existing Staff Full Time Equivalency element (https://ceds.ed.gov/element/000118) to allow values between 0 and 2, up to 2 digits.
Use Case Background
Staff Full Time Equivalency (Global ID 000118) currently has a numeric format between 0 and 1, up to 2 digits.
Michigan collect FTEs between 0 to 2.
For a variety of reasons, a staff member may have an assignment that is greater than a single FTE, and so we need this element to be modified to accommodate those use cases.
Location of Element in the Domain Entity Schema
K12 -> K12 Staff -> Assignment
The text was updated successfully, but these errors were encountered: