mobisys-topic-selection
GitHub辅助判断论文是否适合MobiSys投稿，核心在于确认贡献是否为移动端/嵌入式系统且受设备约束。提供路由指南，将无线、传感器网络或分布式系统等不符项导向MobiCom、SenSys等合适会议。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill mobisys-topic-selection -g -y
SKILL.md
Frontmatter
{
"name": "mobisys-topic-selection",
"description": "Use when deciding whether a project belongs at MobiSys — testing whether the core contribution is a mobile or embedded system, application, or service whose on-device behavior is the result, and routing wireless, sensor-network, distributed-systems, ubicomp, or early-idea misfits to MobiCom, SenSys, NSDI\/OSDI, IMWUT, or HotMobile."
}
MobiSys Topic Selection
MobiSys is the ACM SIGMOBILE venue for mobile systems, applications, and services — the system that runs on the device, not the radio underneath it. The fastest way to waste a year-long cycle is to submit a paper whose real contribution belongs one venue over. This skill is a fit and routing tool, not a substitute for the current CFP scope list.
The fit test
A MobiSys-shaped paper answers all four:
- Is the contribution a mobile or embedded system? A runtime, an OS/platform mechanism, an on-device inference engine, a sensing pipeline, an offload scheduler, a mobile application or service — something built and run on the device, not an algorithm evaluated in the abstract.
- Does the device constraint shape the result? If compute, energy, latency, memory, or thermal budget could be idealized away with no loss, the contribution is probably not MobiSys's.
- Is there on-device evidence, or a credible plan for it? MobiSys expects real phones,
wearables, or embedded boards; a simulation-only story is a fit risk
(
mobisys-experiments). - Would MobiSys's systems-and-services reviewers be the right audience? Say why in one sentence using the venue's vocabulary, not "it is a top conference."
Routing map
Route by contribution type, not prestige. The nearest siblings and what pulls a paper to each:
| Signal in the contribution | Better-fit venue |
|---|---|
| Wireless/PHY-MAC mechanism, protocol, or RF sensing as the core | ACM MobiCom |
| Sensor-network / embedded-sensing infrastructure at large | ACM SenSys |
| Data-center, cloud, or distributed-systems design and implementation | USENIX NSDI / OSDI |
| Operating-system generality beyond mobile | USENIX OSDI / ACM SOSP |
| Ubiquitous-computing / on-body inference as the finding | ACM IMWUT (UbiComp) |
| Security or privacy of mobile as the central claim | a security venue |
| Early idea without a full on-device evaluation | HotMobile or a workshop |
The MobiSys↔MobiCom line is the one authors get wrong most: a wireless mechanism is MobiCom; an end-to-end mobile system whose device behavior is the point is MobiSys. The MobiSys↔SenSys line is the second: a sensing infrastructure is SenSys; a mobile platform, app, or service built on sensing is MobiSys. When two are present, decide which is the contribution and which is the vehicle.
Contribution-type honesty
Name the contribution before choosing the venue:
[Contribution type] mobile runtime / OS-platform mechanism / on-device ML system /
sensing service / offload scheduler / mobile app-service / other
[Device dependence] does the result change if compute/energy/latency is idealized? y/n
[Evidence form] real-device measurement / deployment / user study / trace / simulation-only
[Primary audience] the MobiSys sub-community that should review it
If the type is "on-device ML system," MobiSys rewards a resource-management or runtime contribution (scheduling, approximation, placement, thermal control), not a better model — a new architecture with mobile motivation routes to a machine-learning venue. If it is "sensing service," the mobile system and its on-device budget must be the contribution, not just the sensor.
Common misfit patterns
- The better-model paper. A more accurate network that happens to run on a phone; the system is incidental → a machine-learning venue, unless the runtime is the contribution.
- The wireless paper wearing a systems hat. A link/PHY result with a phone demo → MobiCom.
- The sensor-network paper. A multi-node embedded-sensing infrastructure → SenSys.
- The simulation-only system. A scheduler or runtime evaluated only in a simulator; strong ones still need on-device measurement to clear the bar.
- The distributed-systems paper with a mobile example. A cloud/back-end contribution with a mobile motivating scenario → NSDI/OSDI.
Re-routing decision
If the paper misses MobiSys's bar, do not force it into the December deadline — re-route by type and record why. A wireless mechanism goes to MobiCom, a sensing infrastructure to SenSys, a distributed-systems design to NSDI/OSDI, a ubicomp finding to IMWUT, an early idea to HotMobile. Because MobiSys runs one deadline a year, a misfit costs a full cycle, and the two-round review often surfaces it as an early reject after round 1 rather than a rescue — re-routing early is by far the cheaper move.
Output format
[Fit] High / Medium / Low (one-line reason in MobiSys's vocabulary)
[Contribution type] <named>
[Device dependence] result depends on compute/energy/latency/memory? y/n
[Evidence form] real-device / deployment / user study / trace / simulation-only
[Main gap] the single most important missing system mechanism or measurement
[Re-route] <sibling venue if not a fit, with the signal that sends it there>
Version History
- 9f86f09 Current 2026-07-19 17:04
