← all publishers

brycewang-stanford

@brycewang-stanford source repo

Report this profile Claim this profile

• 5.3k skills
• 0 followers
• 1k repo stars
• 2 weeks ago last updated

1. ▌
   Fcr Workflow · brycewang-stanford

   Use as the entry point for any Field Crops Research (FCR) manuscript. Routes to the right FCR sub-skill based on where you are in the lifecycle and which article type (Original Research Paper, Review, Short Communication, Opinion, Loomis Review) fits. It checks scope-fit first — FCR rejects controlled-environment-only and single-site single-season work — then dispatches; it does not draft content.
   1k repo stars
2. ▌
   Hlr Submission · brycewang-stanford bundle

   Use when running the final pre-submission preflight for the Harvard Law Review (HLR) via HLR's own electronic submission system — manuscript readiness, anonymization, length limits, Bluebook 22nd-edition footnotes, expedite setup, and season timing. Final upload checks; it does not plan the placement strategy (hlr-placement-strategy) or draft content.
   1k repo stars
3. ▌
   Humrel Submission · brycewang-stanford bundle

   Use when running the final pre-submission preflight for Human Relations (HR) via ScholarOne — anonymization, the 13k word cap, SAGE Harvard style, abstract/keywords, AI and data-transparency declarations. Final checks; it does not draft content.
   1k repo stars
4. ▌
   Icassp Artifact Evaluation · brycewang-stanford

   Use when packaging ICASSP code, data, audio or image samples, model checkpoints, scoring scripts, seeds, and logs, even though ICASSP has no formal artifact badge. Covers what signal-processing reviewers actually open, how single-blind review lets artifacts be public from the start, and how to make a task's measurement reproducible turnkey.
   1k repo stars
5. ▌
   Lancet Research In Context · brycewang-stanford

   Use to build The Lancet's signature Research in context panel — the three mandatory headed parts (Evidence before this study, Added value of this study, Implications of all the available evidence), grounded in a systematic literature search with stated databases, terms, and dates. Mandatory for original research Articles.
   1k repo stars
6. ▌
   Mgsci Rebuttal · brycewang-stanford

   Use when planning and drafting the revision and point-by-point response for a Management Science (INFORMS) R&R — prioritizing the Department Editor's binding concerns, addressing analytical-proof or empirical-identification objections, preserving double-anonymization, and keeping the revision within the page cap and Data-and-Code-Disclosure requirements. It handles the post-decision response; it does not run a fresh submission (mgsci-submission).
   1k repo stars
7. ▌
   Mgsci Workflow · brycewang-stanford

   Use when deciding which mgsci-* sub-skill to invoke next, or when sequencing manuscript work from topic selection through rebuttal for a Management Science (INFORMS) manuscript. Routes — it does not replace — the specialized skills, and helps pick the right Department lane (analytical vs empirical).
   1k repo stars
8. ▌
   Mksc Submission · brycewang-stanford

   Use when preparing to submit a Marketing Science manuscript through ScholarOne — blinding for double-anonymous review, choosing the track (regular / Frontiers / Database / Practice), assembling the replication package, the cover letter, preferred AEs/reviewers, and the optional Open Option. Preflight only; it does not interpret decisions (mksc-review-process).
   1k repo stars
9. ▌
   Misq Review Process · brycewang-stanford

   Use to understand how MIS Quarterly's editorial process works and to read a decision letter — the double-anonymous model, the Senior-Editor/Associate-Editor routing where the SE owns the decision, what a major/minor revision versus reject signals, and what to expect across one or more revision rounds. Sets expectations and interprets decisions; the response itself is drafted with misq-rebuttal.
   1k repo stars
10. ▌
    Misq Tables Figures · brycewang-stanford

    Use when designing the exhibits for a MIS Quarterly manuscript — measurement/correlation and structural-model tables for behavioral IS, regression and robustness tables for economics-of-IS, artifact architecture and evaluation exhibits for design science, and a Gioia-style data structure for qualitative work — all sized to fit MISQ's page limit, which counts tables and figures. Late-stage polish; do not run before the contribution and evaluation are settled.
    1k repo stars
11. ▌
    Molcell Highlights · brycewang-stanford

    Use to produce the three signature Cell Press front-matter artifacts for Molecular Cell — Highlights (3–4 bullets, each ≤85 characters), the eTOC/In Brief blurb (~50 words, third-person), and the Graphical Abstract (single-panel visual summary of the mechanism). Late-stage polish.
    1k repo stars
12. ▌
    Molcell Submission · brycewang-stanford bundle

    Use as the final preflight before submitting to Molecular Cell — a complete checklist across mechanism, single-mechanism arc, length budget, figures, STAR Methods, data deposition, numbered references, front-matter artifacts, and required files. Bundles the checklist and cover-letter templates.
    1k repo stars
13. ▌
    Ngeo Submission · brycewang-stanford bundle

    Use when running the final pre-submission preflight for a Nature Geoscience manuscript — word/display-item limits, format, files, online Methods, Supplementary Information, Reporting Summary, data/code availability, and Editorial Manager metadata. Verifies submission readiness; does not write content.
    1k repo stars
14. ▌
    Oopsla Artifact Evaluation · brycewang-stanford

    Use when packaging an artifact for an accepted OOPSLA paper under the SPLASH artifact-evaluation track — surviving the kick-the-tires phase, earning the Functional and Reusable badges, depositing a Zenodo snapshot with a DOI for Available, and aligning artifact claims with the paper's Data-Availability Statement.
    1k repo stars
15. ▌
    Percom Artifact Evaluation · brycewang-stanford

    Use when packaging an IEEE PerCom sensing artifact and dataset for reproducibility and any badging (IEEE Open Research Objects / Results Reproduced, IEEE DataPort or Zenodo deposit), covering what a ubicomp evaluator checks first for human-subjects sensing data, cross-subject reproduction, de-identification, and honest degrees of reproducibility.
    1k repo stars
16. ▌
    Pnasnexus Significance · brycewang-stanford

    Use to write the PNAS Nexus Significance Statement — between 50 and 120 words, in plain language for a broad scientific audience, explaining why the work matters. Required for Research Reports and Stage 2 Registered Reports. Distinct from the abstract. One of the highest-value PNAS Nexus front-matter artifacts.
    1k repo stars
17. ▌
    Recsys Artifact Evaluation · brycewang-stanford

    Use when packaging ACM RecSys code, datasets, splits, trained models, propensity logs, and seeds as an anonymous in-paper repository during review or a public archive after acceptance, even though RecSys has no separate artifact badge — covering what recommender reviewers open first and how to make a top-N ranking table regenerable end to end.
    1k repo stars
18. ▌
    Respol Submission · brycewang-stanford bundle

    Use when running the final pre-submission preflight for Research Policy (RP) via Elsevier's online submission system — article-type choice, length/abstract limits, double-blind anonymization, data & code statement, and the out-of-scope desk-screen. Final checks; it does not draft content.
    1k repo stars
19. ▌
    Rt Journal Match · brycewang-stanford

    Use when an author asks "which journal should I send this to?" or needs the best resubmission target after a reject. Profiles the paper, shortlists candidates from an index of 743 venues with tools/match_venues.py, and ranks them into reach / match / safe with a resubmission ladder. Reads live venue facts from each pack's source-map; defers fit judgment to the venue's own topic-selection skill.
    1k repo stars
20. ▌
    Rt Venue Reframe · brycewang-stanford

    Use after a rejection, or when switching target journals, to turn a manuscript framed for one venue into one framed for another. Produces a concrete reframing diff — introduction arc, contribution claim, evidence to add or cut, house style, format — by reading both venues' own packs. Complements rt-journal-match, which picks the venue; this one does the rewrite plan.
    1k repo stars
21. ▌
    Sensys Artifact Evaluation · brycewang-stanford

    Use when packaging a SenSys artifact for the Artifact Evaluation Committee — choosing which of the three ACM badges (Available, Functional, Reproduced) to pursue, building a hardware-optional evaluation path for reviewers without your testbed, documenting energy and hardware provenance, and passing the smoke run that proves functionality.
    1k repo stars
22. ▌
    Siggraph Author Response · brycewang-stanford

    Use when writing the SIGGRAPH / SIGGRAPH Asia Technical Papers rebuttal, the single 1000-word text-only author response uploaded during the rebuttal window to correct factual errors and answer specific reviewer questions before the Technical Papers Committee meeting, and when planning the change list for a conditionally accepted paper's second-stage revision.
    1k repo stars
23. ▌
    Siggraph Reproducibility · brycewang-stanford

    Use when building the reproducibility story for a SIGGRAPH / TOG paper, covering deterministic result regeneration, scene/mesh/weight provenance, hardware and timing disclosure, floating-point and GPU non-determinism, and a code/data release that a reader or a Graphics Replicability Stamp volunteer can actually run.
    1k repo stars
24. ▌
    Siggraph Topic Selection · brycewang-stanford

    Use before committing a project to SIGGRAPH / SIGGRAPH Asia / TOG, to decide whether the contribution is graphics-shaped and which venue and track fit, routing among SIGGRAPH, SIGGRAPH Asia, direct-to-TOG, and siblings (CVPR/ICCV, CHI/UIST, Eurographics/EGSR/SGP/SCA/HPG/I3D), and whether to aim dual-track or Journal-only.
    1k repo stars
25. ▌
    Sigmetrics Experiments · brycewang-stanford

    Use when designing or auditing ACM SIGMETRICS evaluations, covering theorem-plus-validation rigor, stating and testing modeling assumptions, analysis-vs-simulation agreement, real workloads and traces, fairly tuned baselines, statistics and confidence intervals for stochastic systems, learning guarantees, measurement provenance, and matching evidence to the shape of each performance claim.
    1k repo stars
26. ▌
    Sigmod Artifact Evaluation · brycewang-stanford

    Use when preparing a SIGMOD paper's code and data for the Availability & Reproducibility Initiative (ARI), covering the post-acceptance opt-in, HotCRP artifact registration, the Artifacts Available / Artifacts Evaluated / Results Reproduced badges, evaluator criteria, and the Best Artifact award path.
    1k repo stars
27. ▌
    Tar Methods · brycewang-stanford

    Use when the research design and identification strategy are the bottleneck for a The Accounting Review (TAR) manuscript — choosing the setting, shock, and design that credibly identify an accounting effect, or structuring an analytical model or experiment. Designs the study; it does not run the estimation and robustness (tar-data-analysis) or frame the contribution (tar-contribution-framing).
    1k repo stars
28. ▌
    Artbull Workflow · brycewang-stanford

    Use as the entry point for any The Art Bulletin manuscript in art history. Routes to the right Art Bulletin sub-skill based on where you are in the lifecycle, with early attention to the image-and-permissions workload that art-historical publishing requires. It dispatches; it does not draft content.
    1k repo stars
29. ▌
    Ecj Rebuttal · brycewang-stanford

    Use when a The Economic Journal (EJ) decision letter (R&R or reject-with-encouragement) has arrived and you need to draft the response-to-referees letter and revision plan. Structures the response and the diff; it does not redo the analysis (route back to ecj-identification / ecj-theory-model / ecj-robustness first).
    1k repo stars
30. ▌
    Ecj Workflow · brycewang-stanford

    Use when deciding which ecj-* sub-skill to invoke next, or when sequencing manuscript work from topic selection through rebuttal for a The Economic Journal (EJ) submission. Routes — it does not replace — the specialized skills.
    1k repo stars
31. ▌
    Wp Research Design · brycewang-stanford

    Use when defending the research design of a World Politics manuscript — comparative-historical and case selection, quantitative cross-national identification, qualitative process tracing, experiments, or formal-empirical linkage for cross-case questions. World Politics expects explicit research design and appropriate methods, judged on each tradition's own terms. Strengthens the design; it does not write code.
    1k repo stars
32. ▌
    Wp Theory Building · brycewang-stanford

    Use when building the theoretical argument of a World Politics manuscript so it travels across cases. World Politics rewards arguments that significantly advance theoretical debates in comparative politics and international relations, with explicit mechanisms and scope conditions that generalize beyond one case. Structures the argument; it does not run analyses.
    1k repo stars
33. ▌
    Ipsn Topic Selection · brycewang-stanford

    Use when deciding whether a sensing/embedded project is an IPSN Information-Processing (IP) contribution or a Sensor Platforms, Tools and Design Methods (SPOTS) contribution, and whether it should go to the IPSN lineage (now the merged SenSys at CPS-IoT Week), a CPS-IoT Week neighbor (RTAS/ICCPS/HSCC), MobiSys/MobiCom, INFOCOM, or a signal-processing journal.
    1k repo stars
34. ▌
    Iros Author Response · brycewang-stanford

    Use when responding to IROS reviews given the traditional no-rebuttal model — pre-answering objections in the paper and video before submission, addressing the meta-review through camera-ready edits, writing RA-L response letters for the journal pathway, and drafting reject-to-ICRA/CoRL/RA-L resubmission memos under double-anonymous rules.
    1k repo stars
35. ▌
    Iros Reproducibility · brycewang-stanford

    Use when strengthening IROS reproducibility evidence — splitting rerunnable claims from auditable-only real-robot claims, the hardware specification ledger, calibration and parameter disclosure, log capture discipline, honest code/data availability statements, and sim-to-real accounting, all inside a page budget with no supplementary PDF.
    1k repo stars
36. ▌
    Iros Topic Selection · brycewang-stanford

    Use when deciding whether a project is a strong IROS fit, routing among ICRA, RSS, CoRL, RA-L, T-RO, HRI, and CASE from IROS's seat on the fall IEEE/RSJ calendar, identifying the integrated-system contribution and its embodiment constraint, and sharpening the intelligent-robots-and-systems framing before writing begins.
    1k repo stars
37. ▌
    Isca Author Response · brycewang-stanford

    Use when ISCA reviews arrive and the rebuttal-plus-revision window opens — triaging objections by what a three-week window can actually fix, deciding between textual rebuttal and a revised PDF with new experiments, structuring responses that arm a champion at the PC meeting, and avoiding window-burning mistakes.
    1k repo stars
38. ▌
    Isca Reproducibility · brycewang-stanford

    Use when making an ISCA paper's results regenerable — pinning simulator versions and local patches, archiving per-figure configuration manifests, recording workload provenance and sampling seeds, quantifying run-to-run variation on real hardware, and keeping the environment resurrectable through the February window.
    1k repo stars
39. ▌
    Isca Topic Selection · brycewang-stanford

    Use when deciding whether a project belongs at ISCA, the ACM/IEEE flagship architecture symposium — testing whether the machine itself is the contribution, choosing between ISCA's November gate and the MICRO, HPCA, and ASPLOS seats in the architecture year, and weighing the main track against the industry track.
    1k repo stars
40. ▌
    Issta Supplementary · brycewang-stanford

    Use when deciding what lives in the ISSTA 18-page body versus the artifact and any appendix, covering the no-unlimited-appendix reality, what reviewers will and will not open, splitting a testing/analysis paper between body and package, anonymity of supplementary material, and keeping decision-critical evidence inside the reviewed pages.
    1k repo stars
41. ▌
    Issta Writing Style · brycewang-stanford

    Use when revising an ISSTA paper for a clear testing/analysis contribution, covering the threat-model-then-technique structure, the evaluation contract, a threats-to-validity section that is not boilerplate, claims scoped to the subjects tested, double-anonymous phrasing, and 18-page ACM sigconf discipline that survives specialist reviewers.
    1k repo stars
42. ▌
    Itcs Author Response · brycewang-stanford

    Use to operate under the reality that ITCS has no rebuttal or author-response phase — pre-empting reviewer objections inside the submission, then handling the post-decision situation (camera-ready window on accept, or rerouting and reusing the reviews on reject) since there is no revise-and-resubmit.
    1k repo stars
43. ▌
    Itcs Reproducibility · brycewang-stanford

    Use to make an ITCS paper's mathematics independently checkable — complete proofs of every central claim, self-contained definitions, pinned dependencies on prior results, and a matching full version on arXiv/ECCC/ePrint — the pure-theory analogue of a reproducibility package.
    1k repo stars
44. ▌
    Itcs Topic Selection · brycewang-stanford

    Use when deciding whether a theoretical-computer-science result belongs at ITCS or should be routed to STOC, FOCS, SODA, CCC, ICALP, TCC, or a journal, and when distinguishing ITCS from its depth-first siblings by the conceptual-novelty test — is this a new question, model, or connection worth asking, rather than the deepest theorem of the year.
    1k repo stars
45. ▌
    Micro Supplementary · brycewang-stanford

    Use when deciding where a MICRO paper's supporting material lives, because MICRO allows no appendix at all — triaging content into the 11 reviewed pages, the unlimited references, an anonymized artifact repository, or the post-acceptance two-page artifact appendix, and cutting what fits nowhere.
    1k repo stars
46. ▌
    Micro Writing Style · brycewang-stanford

    Use when drafting or revising a MICRO paper's prose and structure — building the characterization-motivated introduction, budgeting 11 appendix-free pages, drawing the mechanism walkthrough a microarchitect can re-implement, and pairing every speedup claim with its area, storage, and power cost line.
    1k repo stars
47. ▌
    Mind Topic Selection · brycewang-stanford

    Use when deciding whether a philosophy project fits Mind and which content type (article, discussion, book review, critical notice) to target. Mind takes quality as the sole criterion and excludes no area, style, or school, so the test is the significance and defensibility of the thesis, not novelty of topic alone. Helps frame the question; it does not do the philosophy for you.
    1k repo stars
48. ▌
    Mlsys Supplementary · brycewang-stanford

    Use when deciding what goes into an MLSys appendix versus the 10-page body, exploiting the venue's unlimited separately-uploaded appendix that reviewers are not required to read, organizing configs, traces, extended results, and anonymized code pointers, and keeping supplementary material blinded for the research track.
    1k repo stars
49. ▌
    Mlsys Writing Style · brycewang-stanford

    Use when revising an MLSys paper's prose and structure, building the measured-bottleneck opening, naming the mechanism instead of listing optimizations, writing evaluation sections as answers to research questions, quantifying every performance claim with workload context, and fitting the argument into the venue's 10-page two-column body.
    1k repo stars
50. ▌
    Naacl Supplementary · brycewang-stanford

    Use when deciding what goes into the content pages, the uncounted sections, the appendix, and the optional uploads of a NAACL-bound ARR submission — allocating material by what reviewers are actually obliged to read, and keeping glossed language examples and long tables from starving the main argument.
    1k repo stars
51. ▌
    Naacl Writing Style · brycewang-stanford

    Use when revising the prose of a NAACL submission — scoping every claim to the languages and varieties actually tested, presenting non-English examples with glosses that carry the argument, writing a Limitations section that anticipates reviewers, and cutting to the ARR content-page budget without losing the linguistic substance.
    1k repo stars
52. ▌
    Ndss Author Response · brycewang-stanford

    Use when writing an NDSS rebuttal and working the interactive discussion phase — triaging Round-2 reviews under a short window, answering adaptive-attack and ethics objections with pointable evidence, and negotiating toward Accept or a well-scoped Minor/Major Revision.
    1k repo stars
53. ▌
    Ndss Reproducibility · brycewang-stanford

    Use when making an NDSS paper's results reconstructible — snapshotting live-network observations, pinning testbeds and toolchains, scrubbing traces that carry identities, and writing honest availability statements when ethics or vendor embargoes limit release.
    1k repo stars
54. ▌
    Ndss Topic Selection · brycewang-stanford

    Use when deciding whether a security project belongs at NDSS — the Network and Distributed System Security Symposium — or should route to IEEE S&P, USENIX Security, CCS, PETS, IMC, or ACSAC, applying NDSS's networked-adversary and deployment-realism tests before any writing begins.
    1k repo stars
55. ▌
    Nsdi Author Response · brycewang-stanford

    Use when answering NSDI reviewers through the channel the venue actually provides — executing a one-shot revision against the required-issues list, writing the change memo and highlighted diff for the same reviewers, and pre-empting objections inside the submission when no response phase exists.
    1k repo stars
56. ▌
    Nsdi Reproducibility · brycewang-stanford

    Use when making an NSDI paper's results reconstructible — capturing testbed topology, trace provenance, and configuration while experiments run, planning which datasets can ship publicly, and keeping the paper and artifact from drifting apart so badge evaluation and the Community Award stay reachable.
    1k repo stars
57. ▌
    Nsdi Topic Selection · brycewang-stanford

    Use when judging whether a project belongs at NSDI, picking among its research, operational-systems, and frontiers tracks, or re-routing to SIGCOMM, OSDI, SOSP, FAST, or SIGMETRICS — testing the networking-stack contribution, the CFP's out-of-scope lines, and which of the two yearly deadlines to aim at.
    1k repo stars
58. ▌
    Oopsla Experiments · brycewang-stanford

    Use when designing or auditing the evaluation of an OOPSLA paper — matching evidence type to claim type across the venue's spread (benchmarks, corpus studies, case studies, user studies, mechanized proofs), building baselines and workloads that survive the SIGPLAN checklist, and sizing experiments to the round calendar.
    1k repo stars
59. ▌
    Osdi Reproducibility · brycewang-stanford

    Use when building reproducibility into an OSDI systems project — recording hardware, configuration, workload, and measurement provenance while experiments run, keeping paper and artifact from drifting apart, and setting up for the post-acceptance sysartifacts evaluation and open-access scrutiny.
    1k repo stars
60. ▌
    Osdi Topic Selection · brycewang-stanford

    Use when deciding whether a systems project fits OSDI, choosing between its Research and Operational Systems tracks, or routing the work to SOSP, NSDI, FAST, EuroSys, or the post-USENIX ATC instead — applying the built-and-measured test before a December deadline is spent on a misfit.
    1k repo stars
61. ▌
    Percom Experiments · brycewang-stanford

    Use when designing or auditing IEEE PerCom empirical evaluations, covering real human subjects, leave-one-subject-out / cross-subject evaluation, F1 and event-level metrics on imbalanced activity classes, deployment realism (free-living vs. lab), fair baselines, contamination-aware model ablations, and matching evidence to the shape of each pervasive-computing claim.
    1k repo stars
62. ▌
    Pldi Author Response · brycewang-stanford

    Use when drafting a PLDI author response inside the short February window — triaging reviewer objections about soundness, baselines, and benchmark validity, correcting factual errors with pointers into the submitted PDF, and committing to feasible revisions without promising new systems work.
    1k repo stars
63. ▌
    Pldi Reproducibility · brycewang-stanford

    Use when hardening a PLDI paper's measurements against the SIGPLAN Empirical Evaluation Guidelines — warmup and steady-state discipline, variance and confidence reporting, principled benchmark choice, pinned toolchains, cross-platform validity, and a measurement log that survives artifact evaluation.
    1k repo stars
64. ▌
    Pldi Topic Selection · brycewang-stanford

    Use when deciding whether a project is PLDI-shaped — implementation insight with benchmark-grade evidence — or better routed inside the PACMPL family to POPL, OOPSLA, or ICFP, or outward to ASPLOS, CGO, CAV, ICSE/FSE, or a systems venue, based on where the claim's evidence actually lives.
    1k repo stars
65. ▌
    Pmla Topic Selection · brycewang-stanford

    Use when deciding whether a literary or language-studies project fits PMLA (Publications of the Modern Language Association) and which venue to target. PMLA is the discipline's generalist flagship, so the test is interest to scholars and teachers of language and literature broadly, not narrow specialist novelty. Helps frame the question; it does not gather sources.
    1k repo stars
66. ▌
    Pnasnexus Data · brycewang-stanford

    Use to build PNAS Nexus's Data and Code Availability — mandatory public-repository deposition of all materials, data, code, and protocols upon publication, retention of raw unprocessed images, accession numbers/DOIs, the [dataset] citation tag, and a compliant availability statement. "Available on request" alone is not sufficient, and failure can be grounds for rejection or retraction.
    1k repo stars
67. ▌
    Podc Author Response · brycewang-stanford

    Use when writing an ACM PODC rebuttal/author response, if the cycle runs one — covering how to correct a proof misreading, supply a missing lemma or bound within the anonymity envelope, prioritize soundness questions over taste, and behave correctly given that PODC has no revision round to fall back on.
    1k repo stars
68. ▌
    Podc Reproducibility · brycewang-stanford

    Use when making an ACM PODC paper's result independently checkable — reproducibility for a proofs venue, not an artifact venue. Covers a self-contained proof appendix, an explicit and checkable model/assumption box, honest handling of any optional simulation, and keeping the full version (with proofs) in sync with the 10-page camera-ready.
    1k repo stars
69. ▌
    Podc Topic Selection · brycewang-stanford

    Use when deciding whether a distributed-computing result belongs at ACM PODC or should be routed to DISC, SPAA, OPODIS/SIROCCO/SSS, STOC/FOCS/SODA, a systems venue (ICDCS/DSN/OSDI/NSDI), a blockchain-theory venue (AFT/FC), or a journal (JACM / Distributed Computing) — and how to avoid the PODC-vs-PODS naming trap by reasoning about the distributed model and the cost measure.
    1k repo stars
70. ▌
    Pods Author Response · brycewang-stanford

    Use when drafting ACM PODS author responses, covering the short ~48-hour double-anonymous rebuttal that corrects misreadings of proofs and definitions, and — distinctively — the shepherded revision cover letter that maps every required item to a concrete change in the resubmitted paper and survives the shepherd's second read.
    1k repo stars
71. ▌
    Pods Reproducibility · brycewang-stanford

    Use when strengthening the verifiability of an ACM PODS paper — a complete claim-to-proof map, self-contained proofs in the at-submission appendix (no external appendices), correctly stated assumptions, honest scope and open cases, the full-version-on-arXiv norm, and consistency between what the paper claims and what the proofs actually establish.
    1k repo stars
72. ▌
    Pods Topic Selection · brycewang-stanford

    Use when deciding whether a data-management project belongs at ACM PODS (the database-theory symposium) or should be routed to SIGMOD/VLDB/ICDE (systems), ICDT (its sister theory venue), LICS/ICALP/STOC (pure theory), or a journal (TODS/LMCS/JACM), by contribution shape, the result-swap test, and the PODS-vs-ICDT community fit.
    1k repo stars
73. ▌
    Popl Author Response · brycewang-stanford

    Use when drafting a POPL author response during the optional multi-day window — triaging soundness objections against misread definitions, answering "what does Theorem 3 actually assume" questions with pointers rather than new material, staying concise per the CFP, and protecting the path to conditional acceptance.
    1k repo stars
74. ▌
    Popl Reproducibility · brycewang-stanford

    Use when making a POPL paper's results independently checkable — deciding which theorems to mechanize versus hand-prove, maintaining a paper-to-proof correspondence table from day one, keeping on-paper proofs auditable with explicit assumption tracking, and making any accompanying prototype's numbers regenerable.
    1k repo stars
75. ▌
    Popl Topic Selection · brycewang-stanford

    Use when deciding whether a project is POPL-shaped — a principle about programming languages carried by definitions and theorems — or better aimed at PLDI's implementation bar, OOPSLA's breadth, ICFP's paradigm focus, or LICS, CAV, CPP, ESOP, and journal outlets, judged by what the decisive evidence is.
    1k repo stars
76. ▌
    Ppopp Supplementary · brycewang-stanford

    Use when deciding what belongs in a PPoPP paper's 10 reviewed pages versus the artifact or appendix, splitting content by decision-criticality so proofs, full core sweeps, and correctness arguments that determine acceptance stay legible in the body, while bulk data and extended runs move out.
    1k repo stars
77. ▌
    Ppopp Writing Style · brycewang-stanford

    Use when drafting or tightening a PPoPP paper's prose and structure, covering the two-column acmart sigplan layout, the 10-page text+figures budget, stating the concurrency-correctness and scalability claim up front, presenting speedup curves and core sweeps, and the parallel-programming conventions PPoPP reviewers expect.
    1k repo stars
78. ▌
    Recsys Experiments · brycewang-stanford

    Use when designing or auditing ACM RecSys experiments centered on offline-versus-online evaluation — temporal splits, equal-budget baseline tuning, full-ranking versus sampled metrics, off-policy estimators (IPS, SNIPS, doubly robust), A/B tests, exposure and popularity bias, seeds and variance, and matching each recommendation claim to its evidence.
    1k repo stars
79. ▌
    Sensys Experiments · brycewang-stanford

    Use when designing or auditing a SenSys evaluation — energy and low-power measurement with a named instrument, real-testbed and deployment realism, honest sensor ground truth, on-device latency and memory, and same-hardware baselines, so the evidence meets SenSys's built-and-measured bar rather than a simulation or offline-benchmark one.
    1k repo stars
80. ▌
    Sigir Supplementary · brycewang-stanford

    Use when deciding what goes inside a SIGIR paper's page budget versus the cited repository — SIGIR counts appendices inside the 9-page (full) and 4-page (short) limits with only references free, so overflow material must be re-homed into run files, repository docs, or cut, without hiding review-critical evidence outside the paper.
    1k repo stars
81. ▌
    Sigir Writing Style · brycewang-stanford

    Use when drafting or revising prose for a SIGIR paper — the IR register that leads with task, collection, and metric; claim sentences calibrated to significance results; first-page architecture for retrieval contributions; table-centric argumentation; and compressing into the 9-page budget without cutting soundness.
    1k repo stars
82. ▌
    Sigmod Experiments · brycewang-stanford

    Use when designing or auditing the evaluation of a SIGMOD paper, covering workload realism and standard benchmark usage, baseline tuning fairness, scalability and tail-latency methodology, ablations that isolate the mechanism, and the setup disclosure a data-systems PC demands before trusting any speedup.
    1k repo stars
83. ▌
    Socc Author Response · brycewang-stanford

    Use when drafting an ACM SoCC author response (rebuttal) during a round's response window, covering the single written turn, answering both the systems and the data/measurement reviewer, supplying the tail-latency and cost numbers reviewers ask for, staying within dual anonymity, and the fact that SoCC has no Major-Revision round to fall back on.
    1k repo stars
84. ▌
    Socc Reproducibility · brycewang-stanford

    Use when strengthening ACM SoCC reproducibility, covering the testbed and workload description, released code and traces, provenance pinning for measurement studies, reproducing tail-latency and cost (not just the mean), claim-to-evidence mapping, honest degrees of reproducibility, and consistency between what the paper reports and what the artifact regenerates.
    1k repo stars
85. ▌
    Socc Topic Selection · brycewang-stanford

    Use when deciding whether a cloud-computing project belongs at ACM SoCC or should be routed to OSDI, NSDI, EuroSys, USENIX ATC, SOSP, or a data venue (SIGMOD/VLDB), leaning on SoCC's unique joint SIGMOD+SIGOPS identity, its welcome of measurement and experience papers alongside systems-building, and the model-swap and re-label tests.
    1k repo stars
86. ▌
    Sf Rebuttal · brycewang-stanford

    Use when writing the response to a Social Forces (SF) revise-and-resubmit. SF reviewers prize methodological rigor and general significance, and most published papers go through at least one R&R, so the response must convert each reviewer without alienating the editor — all while keeping the revision within the reference-inclusive 10,000-word and 10-panel limits. Structures the response letter; it does not fabricate new results.
    1k repo stars
87. ▌
    Sf Workflow · brycewang-stanford

    Use as the entry point for any Social Forces (SF) manuscript. Routes to the right SF sub-skill based on where you are in the lifecycle, keeping the paper aimed at a general social-science audience and inside the journal's reference-inclusive 10,000-word cap and 10-panel exhibit limit. It dispatches; it does not draft content.
    1k repo stars
88. ▌
    Soda Author Response · brycewang-stanford

    Use when drafting the SODA (ACM-SIAM Symposium on Discrete Algorithms) rebuttal — the roughly three-day window between review release in early September and the response deadline, triaging referee misreadings versus real gaps, and writing terse theorem-anchored replies inside HotCRP without breaking lightweight double-blind rules.
    1k repo stars
89. ▌
    Soda Reproducibility · brycewang-stanford

    Use when hardening the verifiability of a SODA (ACM-SIAM Symposium on Discrete Algorithms) paper, where reproducibility means checkable mathematics — complete proofs in the submitted full version, stable statement-proof correspondence, explicit constants and model assumptions, and certificates for any machine-checked step.
    1k repo stars
90. ▌
    Soda Topic Selection · brycewang-stanford

    Use when deciding whether a result is SODA-shaped (ACM-SIAM Symposium on Discrete Algorithms) — concrete algorithmic problems, data structures, and discrete mathematics with quantitative progress — versus routing to STOC/FOCS, ESA, ICALP, ITCS, SOSA, ALENEX, SoCG, or a journal, judged from SODA's algorithms-first identity.
    1k repo stars
91. ▌
    Sosp Author Response · brycewang-stanford

    Use when drafting a SOSP author response during the pre-PC-meeting rebuttal window, keeping it within the venue's norms — correcting factual errors, answering direct reviewer questions, staying near the 500-word guidance, and never introducing new experiments, new data, or promises of future work.
    1k repo stars
92. ▌
    Sosp Reproducibility · brycewang-stanford

    Use when hardening the reproducibility of a SOSP paper's results before submission — pinning the OS-level environment, recording hardware and topology, making every figure regenerable from logged runs, separating measurement noise from effect size, and preparing the ground for post-acceptance artifact evaluation.
    1k repo stars
93. ▌
    Sosp Topic Selection · brycewang-stanford

    Use when deciding whether a systems project is SOSP-shaped — a built and measured artifact embodying an extractable principle in operating and distributed systems — or better routed to OSDI, EuroSys, USENIX ATC, NSDI, FAST, ASPLOS, VLDB, MLSys, or HotOS, and when to make that call in the project's life.
    1k repo stars
94. ▌
    Stoc Author Response · brycewang-stanford

    Use when planning author-side communication for a STOC (ACM Symposium on Theory of Computing) submission, where no standing rebuttal phase exists — covering pre-emptive writing that answers objections in advance, chair-mediated technical clarifications if the PC asks, and the FOCS resubmission letter after a rejection.
    1k repo stars
95. ▌
    Stoc Reproducibility · brycewang-stanford

    Use when hardening a STOC (ACM Symposium on Theory of Computing) paper so its results can be independently checked — proof completeness across the extended-abstract/full-version split, single-source builds that prevent statement drift between the two documents, and determinism for any computation a claim relies on.
    1k repo stars
96. ▌
    Stoc Topic Selection · brycewang-stanford

    Use when deciding whether a result belongs at STOC (ACM Symposium on Theory of Computing) — testing for broad theory-of-computation significance versus routing to FOCS, SODA, CCC, ITCS, COLT, CRYPTO, PODC, SoCG, EC, or a journal like JACM/SICOMP when the fit is specialized, conceptual, or empirical.
    1k repo stars
97. ▌
    Tacas Supplementary · brycewang-stanford

    Use when deciding what belongs in a TACAS (ETAPS) paper body versus its appendix, supplementary website, and artifact, covering the 16-page (or 6-page) llncs.cls budget that excludes references and appendix, the rule that decision-critical content stays in the reviewed pages, category-appropriate anonymity of supplementary material, and how to split a verification paper between body, appendix, and a mandatory-or-voluntary artifact.
    1k repo stars
98. ▌
    Tacas Writing Style · brycewang-stanford

    Use when revising a TACAS (ETAPS) paper for a clear construction-or-analysis contribution on the first page, a stated soundness/completeness claim, honest benchmark evidence, category-appropriate structure (research vs tool vs case-study vs tool-demo), disciplined use of the 16-page (or 6-page) LNCS budget, and correct handling of double-blind wording for research papers.
    1k repo stars
99. ▌
    Uist Author Response · brycewang-stanford

    Use when writing the UIST rebuttal — budgeting the 5,000-character self-contained response, prioritizing factual corrections and novelty defenses over taste disputes, promising only camera-ready changes you can deliver, and writing for the PC discussion that follows rather than for the reviewers alone.
    1k repo stars
100. ▌
     Uist Reproducibility · brycewang-stanford

     Use when making a UIST paper's results replicable — reporting implementation parameters and measurement protocols so a lab could rebuild the system, specifying hardware down to parts and calibration, logging technical evaluations deterministically, and writing honest availability statements for interface systems.
     1k repo stars