This is the implementation plan for a new feature in Reactive Resume.
Here is a link to the GitHub Issue that sparked this discussion: https://github.com/amruthpillai/reactive-resume/issues/2670#issuecomment-3828872142
Right now, users can use Reactive Resume to create new resumes and export them as PDFs to apply for jobs. But after applying for a job, it loses visibility unless the application is tracked personally.
During a job hunt, an applicant applied to roughly 50-100 job descriptions (for some, this could be in one day). How do they manage to keep up with what companies they applied to, what resume they sent with it, when they applied for it, and what is the progress like.
Implement a new sidebar item in the dashboard “Application Tracking” (name still up for discussion).
In this page, a user can create multiple “Campaigns”. A campaign can be thought of a single job searching journey which could span from weeks to months. The benefit of this historical tracking data, is that users would be able to find out if they had previously applied to this company, and what their response was.
Inside a Campaign page, a Kanban Board is preset for them with the most popular options for swimlanes (lanes). This is yet to be researched, as I don't know what are the different stages of an application tracking system.
Users can create multiple “Application” to track. Each application can contain a Company/Organization Name, their website (this could be used to get the icon for the company, through favicon), a link to the job description if available, and any other notes they may want to add. But most importantly, the can optionally link it to a resume or upload a PDF or any documents of the resume that were sent along with this application.
The “application” can then be dragged/dropped to a specific lane/column indicating it's progress. There should also be an activity log to display when a specific application was created, and when it was moved to a specific lane with detailed timestamps.
This might increase the database size or storage usage of the application. It might become unfeasible to support this in the long run without consistent donations or enterprise support.
The data stored for each application should be properly categorized/tagged, instead of dumping all the information on a single description field, as this would benefit in providing a better user experience (such as optimizing the resume to the job description). But this is a lot of sensitive data to be dealing with, and it might put off certain people from using it.