人工智能机器学习深度学习数据分析【免费下载链接】BasicTSA Fair and Scalable Time Series Forecasting Benchmark and Toolkit.项目地址https://gitcode.com/gh_mirrors/ba/BasicTS点击查看免费下载BasicTS 是一个可复现、可扩展的时间序列分析工具箱与基准测试框架其协作流程被沉淀在 中文贡献指引对应英文版 contribution_guidelines.md中。本文以该文档为主线逐节展开 Issue 的规范报告方式、从 Fork 到 PR 的五步贡献流程、基于 Pylint 与 isort 的代码格式检查配置以及 PR 标题的 mark 约定并结合仓库中的 CI 工作流pylint.yml、python-test.yml、Issue 模板和 smoke test 等真实文件讲清每一条规范在代码库中如何落地、可如何在本地先行验证。读完后你可以独立完成一次符合 BasicTS 项目约定、能通过 CI 静态检查的完整贡献。总体约定先讨论、用英文、安全问题私下报贡献指引在开头给出了三条总体约定建议共同建设时优先使用英文进行交流敏感信息和安全漏洞严禁公开发布在 issue 等位置应直接发送到 duyifan at ict.ac.cn普通问题通过 issue tracker 协作。仓库中的 SECURITY.md 与指引一致报告漏洞的渠道是向 duyifan at ict.ac.cn 发送邮件并建议始终使用 BasicTS 的最新版本以获得最佳安全性。因此凡涉及凭证、漏洞细节、未公开的安全问题一律走邮件渠道不写入公开 issue 或 PR 描述。如何报告 Issues提交前先搜索确保问题未被报告指引要求在 issues 中使用多种相关关键词搜索确认问题尚未被报告后再提交提交时选择合适的 issue 类型以便分类管理并提供清晰且简明的说明——即使复现步骤看起来很简单也要确保维护者能够复现该行为。仓库中.github/ISSUE_TEMPLATE/目录将这一要求落成了具体的表单模板贡献者可以直接对照模板准备内容bug_report.yamlBug 报告模板标题自动加[]前缀并打上bug、needs-triaged标签。表单强制勾选已搜索过已有 issues/讨论和已搜索过 tutorial两个前置项其余字段包括Current Behavior当前行为准确描述遇到的行为Expected Behavior期望行为描述预期行为Environment运行环境模板给出了示例字段——OS、DEVICE、NVIDIA Driver、CUDA、GPU 显存、PyTorch 版本BasicTS logs提示从 checkpoints 目录下找到training_log_xxx.log文件把关键内容粘贴进来Steps To Reproduce复现步骤按环境 → 配置 → 执行的命令 → 报错的顺序列出。feature_request.yaml功能请求模板标题加[⭐]前缀打上needs-triaged、enhancement标签必填项为新功能/能力的预期行为和使用场景选填附加信息日志、论文、相关项目并明确一个 issue 只提一个请求。config.yml关闭了空白 issueblank_issues_enabled: false并把用户引导到项目文档与 FAQ避免无结构的提问占用维护者精力。从模板设计可以看出一个合格的 Bug issue 至少应包含复现步骤、期望/实际行为、完整运行环境与依赖版本、training_log_xxx.log关键日志。这四要素正是指引中确保我们能够复现该行为的具体化。Issues 的三种分类贡献指引给出的分类如下分类说明bug report提交 Bug 或者您遇到的错误信息feature or enhancement request请求新功能特性。需详细描述希望在 BasicTS 中使用的功能及其使用场景使任何阅读该 issue 的人都能理解这个功能应如何实现security issue不在公开 issue 中讨论安全问题直接发送相关信息至 duyifan at ict.ac.cn前两类分别对应上文两个 YAML 模板第三类则指向 SECURITY.md 的邮件渠道。提交贡献的五步流程贡献指引中提交您的贡献一节给出了完整的五步流程下面逐步展开并补充仓库中对应的实操证据。第 1 步先在 issues 中充分讨论在提交重大代码变更之前先在 issue 中讨论您的想法确保其必要性和可行性。这一步对 BasicTS 尤为重要它包含模型架构src/basicts/models/下 28 个模型目录、统一配置体系src/basicts/configs/、Runner/TaskFlow 管线src/basicts/runners/等多层抽象新增一个模型或数据加载器牵涉的模块较多事先讨论可以明确改动边界。第 2 步Fork 仓库并创建新分支Fork 此仓库并为您的工作创建一个新分支避免直接在主分支上堆叠不相关的提交。第 3 步清晰的注释与既有约定开发时添加清晰的代码注释解释您的方法并尽量遵循现有的代码约定。以模型为例仓库中每个模型如 TimesNet都遵循arch/架构实现config/模型配置__init__.py导出的目录约定新增模型时应保持同样的组织方式。第 4 步通过代码格式检查按指引要求运行 Pylint 与 isort 检查详见下文专节。第 5 步提交指向主分支的 PR 并关联 issue提交一个指向main分支的 PRPull Request并关联与之相关的 issue提供详细背景信息并遵循 PR 格式指南。可以说明的是贡献指引原文写的是main分支而从当前仓库的 CI 配置看python-test.yml 与 pylint.yml 的触发分支为master/release/*或任意 push/PR实际操作时以仓库当前的默认分支为准。指引最后也提示维护者会尽快评估 PR 并与贡献者协作整合评估需要时间请耐心等待通过审核后代码将被合并。代码格式检查Pylint 与 isort 的完整配置解读指引对格式检查的要求是项目使用Pylint进行代码格式检查并使用isort对 import 依赖部分进行自动排序并特别提醒——由于 baseline 部分可能包含一些外部实现这部分不强制进行代码检查但也请尽量保持代码高效整洁。标准操作三步安装 Pylint 和 isort在项目根目录运行pylint进行格式检查pylintrc位于项目根目录在项目根目录运行isort进行依赖排序isort.cfg位于项目根目录。强调在根目录运行是因为两份配置文件都放在仓库根目录。下面结合仓库中的真实配置解读其约束内容。.pylintrc基于 Google Python Style Guide 的定制.pylintrc 文件头注释说明这份配置是对 Google Python style guide 最佳实践的best-effort落地。对贡献者最相关的几处设置检查范围排除ignorebaselines,assets,checkpoints,examples,scripts.pylintrc#L11。这里同时解释了指引中baseline 不强制检查的出处——baselines目录被显式列入忽略清单外部实现的 baseline 代码不受 Pylint 约束。行长max-line-length180.pylintrc#L269远宽松于 Pylint 默认的 100URL 行和import行允许超长ignore-long-lines正则。命名规范变量与参数需匹配^[a-z][a-z0-9_]*$snake_case类名匹配^_?[A-Z][a-zA-Z0-9]*$函数/方法允许 snake_case 或 camelCasetest、test*、*Test命名的函数豁免 docstring 要求。宽松化disable列表中关闭了too-many-arguments、too-many-locals、too-many-branches、missing-function-docstring、no-member等大量规则invalid-name也被禁用因此不必纠结于复杂度的告警风暴。评分公式evaluation10.0 - ((float(5 * error warning refactor convention) / statement) * 10).pylintrc#L173error 的权重是其他类别的 5 倍。.isort.cfgimport 排序的两个约束.isort.cfg 非常简短只有两条设置[settings] src_pathssrc/basicts,tests skip_globbaselines/*,assets/*src_paths声明src/basicts和tests是本地源码路径使 isort 能把from basicts.xxx import ...正确识别为 first-party import 而非 third-party这与 pyproject.toml 中package-dir { src}的 src 布局一致skip_glob再次把baselines/*排除在自动排序之外与 Pylint 的ignore保持一致。CI 中的实际检查命令最值得参考的是 CI 中真正执行的命令。pylint.yml 在 Python 3.9 环境下对 push 和 pull_request 事件运行pylint --fail-under10.0 src/basicts scripts tests isort -c src/basicts scripts tests两条命令透露了明确的检查边界静态检查只覆盖src/basicts、scripts、tests三个目录--fail-under10.0要求 Pylint 总分达到 10.0即 error/warning/refactor/convention 基本清零才会通过isort -c是 check 模式只校验 import 顺序而不修改文件顺序不对则 CI 失败结合本地操作贡献者提交前应在仓库根目录运行isort src/basicts scripts tests自动修复 import 顺序再运行pylint src/basicts scripts tests查看剩余问题。PR 格式指南指引要求 PR 尽量易于评估具体有三条保持 PR 专注于事前讨论好的代码不包含无关部分允许维护者编辑您的 PRAllow edits by maintainers这样维护者可以在之后负责合并而无需您操作PR 标题使用mark title格式可用的 mark 如下表表格完整继承自贡献指引mark含义docs:文档变更fix:bug 修复tests:测试feat:新功能特性chore:项目杂项style:代码风格维护也就是说一次新增模型实现的 PR 标题应写作类似feat: add xxx model for forecasting一次修复数据集加载问题的 PR 写作fix: xxx。这个约定也与仓库 .all-contributorsrc 中commitConvention: angular的角式提交规范相互呼应便于提交历史与贡献统计归类。提交前本地验证借助 smoke test 快速跑通虽然贡献指引未单独要求运行测试但仓库提供了完整的自动化验证手段建议在 PR 中同步说明你已本地验证。CI 侧python-test.yml 在 Python 3.9与 pyproject.toml 中requires-python 3.9一致环境安装requirements.txt与tests/requirements.txt后者仅含einops后直接执行pytest。测试侧tests/smoke_test/ 目录包含 22 个冒烟测试文件覆盖 TimesNet、PatchTST、iTransformer、DLinear、Informer、Koopa 等模型。这些测试的共同模式是用sys.path挂载src/chdir到测试目录然后以极小配置调用BasicTSLauncher.launch_training训练 1 个 epoch。例如 test_timesnet.pydef test_timesnet_smoke_test(): output_len 24 input_len 96 timesnet_config TimesNetConfig( input_leninput_len, output_lenoutput_len, num_features7, use_timestampsTrue, timestamp_sizes[24, 7, 31, 366], hidden_size16, intermediate_size64, ) BasicTSLauncher.launch_training( BasicTSForecastingConfig( modelTimesNetForForecasting, dataset_nameETTh1_mini, model_configtimesnet_config, gpusNone, num_epochs1, input_leninput_len, output_lenoutput_len, lr0.001 ) )测试所用的ETTh1_mini等 mini 数据集元信息放在 tests/smoke_test/datasets/ETTh1_mini/meta.json其中声明了 shape[720, 7]、训练/验证/测试比例 0.6/0.2/0.2、评估指标 MAE 与 MSE。从源码结构看这种mini 数据集 1 epoch 小 hidden_size的设计就是为了保证每个模型测试都能快速跑通验证配置解析、数据加载、训练循环与指标计算的整条管线。若你改动了src/basicts/configs/、src/basicts/runners/等公共路径建议参照 test_patchtstforf.py 的模式为本模块补充相应测试并以tests:mark 提交。贡献前自检清单综合贡献指引与仓库配置提交 PR 前可逐项核对是否已在 issue 中讨论过该变更的必要性与可行性PR 中关联了相应 issue标题是否为mark title格式docs/fix/tests/feat/chore/style 之一在仓库根目录运行pylint --fail-under10.0 src/basicts scripts tests是否达标运行isort -c src/basicts scripts tests是否通过PR 是否只包含与事前讨论相关的改动并已允许维护者编辑是否未把敏感信息或安全漏洞写入公开 issue/PR涉及公共代码路径时是否补充或运行了相应 smoke test 并说明验证结果。遵循以上流程你的贡献就能在协作沟通、代码风格与自动化验证三个维度上与 BasicTS 现有代码库保持一致显著提高 PR 的评估与合并效率。赞分享人工智能机器学习深度学习数据分析【免费下载链接】BasicTSA Fair and Scalable Time Series Forecasting Benchmark and Toolkit.项目地址https://gitcode.com/gh_mirrors/ba/BasicTS点击查看免费下载相关推荐Safari 里 AV1 视频黑屏卡顿LiveKit 自动编解码适配 3 步落地指南Safari 里 AV1 视频黑屏卡顿LiveKit 自动编解码适配 3 步落地指南 你大概遇到过Chrome 里画面清晰流畅切到 Safari 对方视频后端音视频即时通讯AI Agent深入解读 Apache Weex 贡献指南Issue、PR、代码规范与 Apache 治理协作全流程深入解读 Apache Weex 贡献指南Issue、PR、代码规范与 Apache 治理协作全流程 本文以 Apache WeexIncubating仓移动开发跨平台原生移动前端CKEditor 5 贡献指南从 Issue 到 PR 的完整协作流程与工程规范CKEditor 5 贡献指南从 Issue 到 PR 的完整协作流程与工程规范 CKEditor 5 是一个模块化架构的开源富文本编辑器框架其代码库以单一前端富文本UI组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考