Using Language Support Information During Project Planning

Reviewing language support before defining project scope

When you start planning a new project in Atloria, review the language and framework support information before you decide what the project will include. This is the point where you compare your team’s real source material against what Atloria can work with directly. If you already reviewed the broader support list in Evaluating Supported Languages and Framework Coverage, use that as your reference and focus here on planning decisions.

1. Open the area in Atloria where you review supported languages and frameworks for code parsing and source coverage.
2. List the repositories, codebases, and existing documentation sources your team wants to include in the project.
3. For each item, check whether its primary language or framework appears in the supported list.
4. Separate your planned sources into three groups:
   • supported for direct source connection
   • supported for code parsing
   • not clearly supported
5. For each repository or content source, decide whether Atloria will analyze it directly, use it only as authored documentation input, or leave it out of automated analysis.
6. Record that decision in your project notes before anyone starts setup.

This review helps you avoid defining a project scope that depends on unsupported inputs. For example, one repository may be a good fit for code upload and parsing, while another may only contribute existing written documentation. A mixed project is often the most realistic option.

As you review each source, stay specific. Do not mark an entire product as “supported” unless the actual repository, language, and documentation source all match what Atloria can use. That level of detail makes later onboarding much smoother and reduces confusion when the team begins connecting sources or uploading code.

Deciding when to connect source content and when to upload code

After you confirm what Atloria supports, decide how each source should enter the project. The main planning choice is whether to connect a source that Atloria can keep in sync, upload code for parsing as a snapshot, or use both methods for different parts of the same project.

1. Review each planned source and identify what it contains:
   • authored documentation
   • source code
   • both code and written docs
2. For sources your team updates regularly, decide whether ongoing connection matters for the project.
3. For codebases you mainly want to inspect for structure or technical reference material, check whether code upload and parsing is the better fit.
4. If a framework is supported for parsing but the team’s authored content is not available as a direct connection option, plan to upload code while managing written docs separately in Atloria.
5. Mark each source with one of these planning decisions:
   • connect source content
   • upload code
   • use a mixed approach
6. Review the list with the people responsible for project setup so everyone agrees before work begins.

Use direct source connection when the team needs ongoing updates from a supported content source. Use code upload when the goal is point-in-time analysis of a codebase that Atloria can parse. A mixed approach works well when your team wants live documentation content from one source and parsed technical insight from another.

This decision should be based on practical workflow needs, not preference alone. If a repository changes every day and the team expects documentation to stay aligned, connection planning matters more. If the team only needs a one-time technical pass for a release, uploading code may be enough. Making that distinction early keeps your project setup realistic.

Planning documentation coverage around supported and unsupported technologies

Once you know which languages and frameworks Atloria supports, use that information to shape documentation coverage. This is where planning becomes more than a yes-or-no support check. You are deciding which areas of the project can benefit from parser-driven discovery and which areas will still need manual documentation work.

1. Group your planned repositories by primary language and framework.
2. Mark which groups are supported for parsing and which are not.
3. Identify the documentation outputs you expect from each group, such as technical reference material, code-informed structure, or manually written guides.
4. For unsupported or mixed-support repositories, plan manual writing work instead of assuming Atloria will generate structure from code.
5. Prioritize the repositories that combine:
   • strong language support
   • important product coverage
   • high documentation value
6. Move lower-value or unsupported repositories into a later phase if needed.

This approach helps you set realistic expectations. Supported codebases may help your team move faster when creating technical reference content or exploring implementation details inside a project workspace. Unsupported languages, custom frameworks, or heavily mixed repositories usually require more manual review and more input from subject matter experts.

Be especially careful with mixed-language repositories. One part of the codebase may fit Atloria’s parsing support well, while another part may not. Instead of treating the whole repository the same way, plan coverage by component, directory, or product area. That gives Documentation Managers a clearer picture of what can be accelerated and what still needs hands-on authoring.

Aligning project roles on scope and ingestion decisions

Language support planning works best when the Project Administrator and Documentation Manager review the same decisions before the project is created. In Atloria, this alignment prevents setup delays and avoids assumptions about what connected sources or parsed code will deliver.

1. Have the Project Administrator review each planned source and confirm whether the team can actually use the intended setup path, such as source connection or code upload.
2. Have the Documentation Manager review the same list and mark which documentation sets can rely on parsed code insight and which will depend on existing written material.
3. Create a shared planning record for every repository or source with one clear status:
   • connect source content
   • upload code for parsing
   • exclude from automated analysis
4. Review any mismatches immediately. For example, one person may expect live sync while another is planning a one-time upload.
5. Finalize scope only after both roles agree on the source method and expected documentation outcome.

A simple shared record is often enough, as long as it is specific. The important part is that each repository has one agreed path in Atloria. Without that agreement, teams often promise parser-based outputs for unsupported frameworks or assume a source can stay synced when the plan only supports a one-time code upload.

Keep the conversation tied to actual project assets. Instead of discussing support in general terms, review each repository, documentation source, and expected output one by one. That makes it easier to spot planning gaps before anyone starts onboarding the project or preparing source material.

Estimating effort for projects with partial language support

Projects rarely fit into a single support category. In Atloria, some repositories may be fully supported for parsing, others may only contribute written documentation, and some may need entirely manual treatment. A simple planning table helps you estimate effort without overpromising speed or automation.

Use a table like this during planning:

When you fill out this table, estimate lower effort for repositories where Atloria can help with code-informed discovery. Those areas may move faster because the team can work from parsed structure and technical reference material. Estimate more time for unsupported languages, generated code, or proprietary frameworks, because those areas usually require manual review, interviews, and existing internal documents.

The table also helps you separate planning into two work types:

• accelerated work supported by connected sources or parsed code
• manual work that depends on human review and writing

This kind of estimate is especially useful when you need to phase a project. Start with the repositories that offer the best combination of support coverage and business value, then schedule manual-heavy areas after the first release or onboarding cycle.

Handling common planning issues with language support information

Even with a support list in front of you, planning questions still come up. Most of them happen when teams assume support means more than it actually does, or when a repository does not fit neatly into one category. In Atloria, the best response is to turn each issue into a clear planning decision before setup begins.

1. If a required repository uses a language or framework that is not listed as supported, remove parser-based expectations from the project plan.
2. Decide how that repository will be documented instead, such as using existing written material or manual authoring in Atloria.
3. If the team is unsure whether to connect a source or upload code, compare the real need:
   • continuous updates and synchronization
   • one-time code analysis
4. If a repository contains multiple languages, split the plan by component, directory, or product area instead of giving the whole repository one support label.
5. If stakeholders expect complete automation, review exactly which parts of the workflow Atloria can accelerate and which still require editorial review.

Common issues usually fall into a few patterns:

• Unsupported technology: plan manual documentation and avoid promising generated technical coverage.
• Unclear ingestion path: choose based on ongoing sync needs versus snapshot analysis.
• Mixed-support repository: break planning into smaller parts.
• Overstated expectations: explain that support helps with discovery and acceleration, not automatic completion of all documentation work.

When you handle these issues early, project scope stays credible. That matters most when multiple teams are involved, because unclear support assumptions can affect timelines, staffing, and release expectations long before any content is created.

Overview

• This guide focuses on using Atloria’s language and framework support information to make project planning decisions before setup begins.
• Use it when you need to decide:
  • which repositories belong in scope
  • whether a source should be connected or uploaded
  • which areas can benefit from code parsing
  • which areas require manual documentation planning
• This guide builds on Evaluating Supported Languages and Framework Coverage, so it does not repeat the full support review process.
• The main planning outcome is a per-repository decision that clearly states whether the team will:
  • connect source content
  • upload code for parsing
  • use a mixed approach
  • exclude the source from automated analysis
• Atloria planning is most effective when support status is reviewed alongside real project inputs such as repositories, documentation sources, and expected deliverables.
• Use [SCREENSHOT: support list beside repository planning notes] if you want to show stakeholders how support information translates into scope decisions.

Prerequisites

• Before using this planning approach in Atloria, make sure you have:
  • reviewed the current supported languages and frameworks
  • a list of repositories, codebases, or documentation sources the project may include
  • a rough idea of the documentation outputs the team expects
• It helps to involve both of these roles during planning:
  • Project Administrator
  • Documentation Manager
• Gather the following details for each planned source:
  • primary language
  • framework, if relevant
  • whether the source changes frequently
  • whether the team needs ongoing sync or one-time analysis
• If your team is still comparing support coverage at a general level, read Evaluating Supported Languages and Framework Coverage first.
• After you finish scope planning, continue with Understanding Parser Availability Before Code Upload to confirm what to check before uploading code into Atloria.