2024 JANUARY 12

In this month’s issue:

1. ‘Move to Development’ tickets

2. The NAP code

3. Negative reports

4. New numbering

5. Deprecated pages

1. Jira tickets with status changed to "Moved to Development"

The MPC User Group Meeting took place on December 7–8, 2023 at the University of Maryland in College Park (MD). We would like to thank our user group representatives for taking the time to report to us the community feedback and for their constructive suggestions and concerns.

These meetings are a good venue for the MPC to understand whether or not our processes are clear to the community. At this meeting it became obvious that our users didn’t really know what happens behind the scenes when we change the status of a ticket to ‘Moved to Development’. As such, we are taking this opportunity to clarify.

Overview

Some of the helpdesk tickets submitted to the MPC cannot be resolved immediately for various reasons. They include for example:

1. Requests for new features or services,

2. The re-implementation of services or files that are no longer produced, or

3. Other work that requires effort beyond typical day-to-day operations of the MPC.

We welcome requests like these from our users and we are happy to see them coming through, but unfortunately we do not have resources available to implement all user requests at the time of the request. To acknowledge that these requests would be valuable to implement, we set the ticket status to “Moved to Development”.

When a ticket changes its status to ‘Moved to Development’, we create or link a matching task in our software development system. Approximately 3% of the tickets submitted to the MPC are now “Moved to Development”, and not all of these currently have resources assigned. The “Moved to Development” status is assessed by the MPC team, and a priority is also determined. The priorities are usually defined as “Low”, “Medium”, or “High”, and the priority of the Helpdesk ticket will match the priority of the related task in our internal Development tracking system.

We review all of these tickets every few months, with one of the main goals being to determine whether the priority is still appropriate. If similar requests are submitted by multiple users, this can affect the priority assessment of tickets and as a consequence the resources allocated to implement the request.

What do the priorities mean?

High: This ticket relates to important and timely issues or services at the MPC. The software development task is assigned to a staff member, and work is currently ongoing. The majority of High priority tasks are likely to be completed within the timescale of our next internal software release (~3 months), though particularly large development projects may be marked as High if significant progress will be made by the next release.

Medium: The linked software development task is assigned and may be worked on within this internal release.

Low: These tasks are not expected to be completed or worked on before the next internal release. Staff may work on these if time permits, but progress likely won’t occur unless the priority is changed.

How to check the priority of your tickets

Log in to the MPC Helpdesk here. On the upper right, click ‘Requests’ and select one of the options. This will show a table of all relevant tickets, with the priorities listed on the right-hand side. If the ticket(s) you are looking for are unavailable, you may need to add additional options in the ‘Status’ selection, which typically defaults to ‘Open Tickets’. Add ‘Moved to Development’ to include these as well.

This view also shows the “Assignee” and “Updated date”, which will reflect the last time an MPC staff member changed something in the ticket.

What does this mean for my Moved to Development ticket?

A user with a “Moved to Development” ticket may see its “Priority” and “Assignee” change over time. A ticket “High” priority is likely to have progress reported in the following few months, a “Medium” priority ticket may have some work done, and a “Low” priority ticket may not have work done unless its priority changes.

We typically do not add comments to these tickets until the issues are resolved, at which point the staff member who worked on the development task will put a summary into the “Moved to Development” ticket and mark that as “Resolved”. If users want to check on the status of work related to their ticket, they can comment on it and request updates. However, Low priority tasks are unlikely to have any updates.

We have also added this explanation to our FAQs page.

NEOCP Automatic Processing (NAP) code

When there is sufficient astrometry to determine a well-constrained orbit for an NEOCP object, and the object is believed to be new, if the object is either an NEO or a distant object (q > 5.6 AU), the discovery is announced in an MPEC.

As already mentioned in our April 2023 Newsletter, we have been working on an automated script that is able to automatically process and designate objects on the NEOCP. Before being automatically MPEC’ed, the object goes through a verification process that includes a large number of different checks. The pie chart in Fig. 2 shows the percentage of objects successfully designated by the NAP code between January and April 2023, plus all the other cases and reasons why the code stopped before designating the object (some similar reasons have been lumped together).

As it is clear from Fig. 2, some of the main reasons for the code to stop were related to possible links to known objects and possible links to ITF tracklets. In the last months we have been focusing on improving those areas and we have made huge progress in increasing the success rate.

Figure 3 shows an updated pie chart generated at the end of December 2023 and covering the period between November 6, 2023, when the most recent development was implemented, and December 31, 2023. The chart shows a huge improvement in the number of success cases, as well as a dramatic reduction in the number of possible links to known objects and possible links to ITF tracklets. This is the result of recent development:

1. Most of the links were not actually real. They are now checked using the available information on the orbit uncertainty from the covariance matrix.
   a. If the possible match does not lie inside three times the ephemeris uncertainty produced by the covariance matrix, the link is automatically excluded;
   b. The ones that are not excluded are left on the NEOCP and can be manually checked;
   c. Any MPC member can manually check the proposed links and mark the object as ‘ready-to-go’ if they believe none of the candidates are real links. In those cases, NAP will skip the step where it checks for links to known objects or ITF tracklets and it will process the object (assuming no other checks cause it to stop).

2. We now also check for differences in magnitudes between the object and the possible ITF links. This automatically excludes many of the false positive matches.

3. Also, the code now runs every 10 minutes, but only attempts to process objects that had received new observations in the last 10 minutes. There is an exception of a 2.5 hour window around the DOU after which the NAP code attempts to process all the objects on the NEOCP.

We are now planning to focus our attention on improving the automatic processing of the short-arc (<24 hr) cases.

Negative reports

Now that we are moving towards a more automated publication system, it would be very useful to us if you could start submitting negative reports for NEOCP objects. Please use our NEOCP Follow-up report form to report unsuccessful attempts to detect objects that are listed on the NEOCP and that have not been updated in the past 24 hours. The most recent reports are also available through the NEOCP Follow-up reports page.

Assigning numbers to discovered asteroids

The selection of objects for numbering is an automatic process performed just before the preparation of each monthly circular. In the last years we are aware that we have not been constant in assigning new numbers. This happened for various reasons, from:

1. the use of legacy code that was inappropriate for the large amount of data we are handling now;

2. the work we were doing on validating our monthly products; and

3. the introduction of the new packed numbering scheme that required extensive testing and validation.

As shown in Fig. 4, the number of numbered objects during every monthly circular did not follow a constant trend. There have been peaks, but also lows, especially between 2022 and 2023, mostly due to the introduction of the new packed scheme. Now we are back on track: we are continuously updating the orbits for the new ‘to-be-numbered’ objects and we are also performing internal linking before the object goes out in the publications. This should avoid bottlenecks during the preparation of the monthly circulars and it should allow us to be able to work through the outstanding list of objects that still need to be numbered.

Deprecated pages

We are in the process of cleaning and restructuring the main menu of the MPC website. While doing this, we are also removing deprecated pages, which means pages that don’t work anymore or that have been replaced by new development or tools.

We want to remind the users that the links are listed on this page: https://minorplanetcenter.net/deprecated-pages.html. We use it to alert the users of upcoming deletions and to keep track of what has already been deleted.

If you are still using one of the deleted pages and you can’t find a new corresponding page/tool or if you notice that we have missed any stale links, please open a Jira ticket and let us know.