Grid Computing Now welcomes proposals from knowledgeable professionals, researchers and practitioners who can contribute clear, accurate and useful perspectives on modern infrastructure and distributed computing. These Contributor Guidelines explain the subjects we consider, the standards expected of proposed work, how submissions are assessed and the principles that apply to editing, attribution and publication.
About the publication
Grid Computing Now is an independent technology publication examining the systems, infrastructure and engineering practices that support modern computing. Its coverage includes grid and distributed computing, high-performance computing (HPC), cloud and hybrid infrastructure, edge computing, AI infrastructure, data-centre technologies, networking, storage, orchestration, resilience and related enterprise subjects.
We aim to publish material that helps readers understand technical developments and their practical implications. We value clear explanations, sound evidence, appropriate context and a distinction between established capabilities, emerging research, commercial claims and informed opinion. Contributors should review our About Us page before proposing an article to ensure that the subject fits the publication’s remit.
Who can contribute?
We welcome proposals from people with relevant knowledge or experience, including engineers, architects, developers, researchers, academics, technical leaders, infrastructure operators, consultants and other subject specialists. A formal academic qualification is not required for every topic, but contributors should be able to explain the basis of their expertise and support technical statements with appropriate evidence.
We assess the quality and relevance of a proposal rather than relying solely on job titles, organisational status or promotional biographies. Contributors should be transparent about their professional role and any relationship with products, vendors, services or organisations discussed in their work.
Subjects we consider
Potential contributions should relate directly to the publication’s areas of coverage. Suitable subjects may include:
- Distributed systems architecture, resource coordination and workload scheduling.
- High-performance computing, accelerators, parallel processing and scientific computing.
- Cloud, hybrid cloud, private infrastructure and workload portability.
- Edge computing, industrial infrastructure and latency-sensitive systems.
- AI infrastructure, GPU clusters, model deployment and orchestration.
- Data-centre design, power, cooling, storage and network architecture.
- Infrastructure security, resilience, observability and operational governance.
- Technical standards, interoperability, open-source infrastructure and emerging research.
- Migration, integration, modernisation and the operational realities of enterprise systems.
We are particularly interested in work that explains why a technical development matters, the conditions under which it is useful, the trade-offs involved and what evidence supports the conclusions. A product announcement or lightly rewritten press release is unlikely to provide sufficient independent value.
Types of contribution
Technical explainers
Explain a technology, architecture, protocol or engineering concept accurately and accessibly. Define specialist terminology, provide relevant context and distinguish conceptual descriptions from implementation-specific details.
Architecture and engineering analysis
Examine design decisions, system components, dependencies, performance characteristics and operational trade-offs. Where possible, explain the assumptions behind an architecture and the circumstances in which another design might be more appropriate.
Research and evidence-led analysis
Interpret research findings, standards developments, benchmark results or public technical evidence. Identify the source material and explain its limitations. Do not present preliminary results or vendor-sponsored findings as settled independent consensus.
Operational case studies
Describe a real implementation, migration, deployment or operational challenge. Explain the environment, constraints, methods and outcomes. Contributors must have permission to share the information and must remove confidential or security-sensitive details.
Opinion and industry perspective
We may consider clearly identified opinion where it is informed, reasoned and relevant to readers. Opinions should engage with evidence and acknowledge credible alternative interpretations. Unsupported predictions, sweeping claims and disguised advertising are not suitable.
Originality and previous publication
Submissions should be original work prepared for consideration by Grid Computing Now. Contributors must disclose whether the material, or a substantially similar version, has appeared elsewhere or is being considered by another publication. We do not accept plagiarism, unattributed copying, spun content or material that reproduces another publisher’s work without permission.
Where a proposal builds on the contributor’s previous research, presentation, report or article, explain the relationship and identify what is new. Reusing the same material across multiple websites without disclosure can mislead readers and undermine the value of the publication. Contributors are responsible for securing any permissions needed for text, diagrams, photographs, code, datasets and other third-party material.
Evidence, citations and technical accuracy
Technical claims should be supported by sources appropriate to the claim. Prefer primary research, official specifications, standards documents, product documentation, public datasets and direct evidence where available. Contributors working on standards, security or infrastructure research may consult the NIST publications catalogue as one source of technical material, while checking the original standard or specification relevant to the claim. Secondary commentary can help explain context but should not replace the original source for a material factual claim when the original is accessible.
Links should lead to the specific source being discussed rather than a generic homepage wherever possible. Include the author or organisation, title and date when these details help readers identify the evidence. Check that cited sources support the statements attached to them. Do not invent references, quotations, test results, customer outcomes or statistics.
For performance claims, identify relevant test conditions such as hardware, software versions, configuration, workload, dataset, measurement method and limitations. Explain whether figures are independently measured, reported by a vendor, drawn from published research or supplied by a customer. Avoid presenting a result from one configuration as a universal performance guarantee.
Our Sources and Research Methodology page explains the evidence principles that guide the publication. Contributors should use it as a practical reference when preparing research-led work.
Structure, style and readability
Write for technically informed readers who may work in different parts of the infrastructure ecosystem. A specialist audience does not require unnecessarily dense prose. Explain acronyms on first use, define uncommon terms and use headings that accurately describe the section that follows.
Submissions should have a clear central question or argument. Use an introduction that establishes the subject and its relevance, followed by a logical progression of evidence and analysis. Conclude with a balanced account of the implications, limitations or practical considerations. Avoid repetitive introductions, keyword stuffing, exaggerated claims and generic conclusions that add no new information.
Use tables, diagrams, code examples or lists only when they improve understanding. Every visual should have a clear purpose, an appropriate caption and alternative text where applicable. Code and configuration examples should be checked, labelled with relevant versions or assumptions, and stripped of credentials, private endpoints and sensitive operational details.
AI tools and automated assistance
Contributors may use software tools to assist with research organisation, editing or drafting, but they remain responsible for every submitted statement and reference. AI-generated material can contain fabricated citations, inaccurate technical explanations, obsolete details and code that appears plausible but does not work. All such material must be independently checked against reliable sources and, where appropriate, tested.
Do not submit unreviewed automated output, fabricated expert quotations, synthetic case studies presented as real deployments or references that have not been opened and verified. Disclose substantial AI assistance where it is relevant to understanding how the work was produced or assessing its originality. Do not upload confidential, personal or restricted information to third-party tools without authorisation.
Conflicts of interest and commercial relationships
Contributors must disclose relevant financial, employment, advisory, ownership, sponsorship or other relationships that could reasonably be perceived as influencing their analysis. This is particularly important when discussing an employer’s products, a client’s infrastructure, a competitor, an investment or a service from which the contributor benefits.
Submissions must not disguise advertising, affiliate promotion, lead generation or link-building as independent technical analysis. Product references should be relevant to the subject and supported by accurate information. Payment, product access, gifts or commercial relationships do not entitle a contributor to favourable coverage or control over editorial conclusions.
Grid Computing Now aims to preserve editorial independence. Our Editorial Standards and Governance page sets out the publication’s stated approach to accuracy, sourcing and independence. Acceptance of a contribution does not imply endorsement of the author’s employer, products or opinions.
Confidentiality, security and legal permissions
Do not submit confidential client information, unpublished security vulnerabilities, personal data, trade secrets, export-controlled material or restricted technical information unless you have confirmed that disclosure is lawful and authorised. Remove credentials, access tokens, private keys, internal hostnames, personal identifiers and other details that could expose systems or individuals.
Contributors must have the right to submit all material and must obtain permissions for third-party images, diagrams, datasets, code and quotations where required. Do not include defamatory allegations, unlawfully obtained material or information that breaches contractual, privacy or intellectual-property obligations. If a proposed article concerns a sensitive security issue, contact the publication through an established and appropriate channel before sending technical details.
How to propose a contribution
A proposal should include a working title, a short summary of the central argument, the intended readership, the proposed structure or main points, the contributor’s relevant experience and a short list of key sources. Identify any commercial relationships or previous publication. If the article is based on a deployment or research project, explain what evidence and permissions are available.
Please do not send a complete confidential report or large attachment as an initial approach. A concise proposal is usually sufficient for an initial assessment. The publication’s Contact Us page describes the intended enquiry route. A working public contact method must be configured on the site before proposals can be submitted through it; do not assume that a form or email address is operational until it is published and tested.
Editorial assessment and possible outcomes
Proposals and submissions may be assessed for relevance, originality, evidence, clarity, technical accuracy, reader value, legal and security risks, and potential conflicts of interest. We may request further information, supporting references, revisions or clarification of the contributor’s role. We may decline material that is outside scope, insufficiently supported, promotional, derivative or unsuitable for publication.
Submitting a proposal does not create an agreement to publish, a commission, an employment relationship or an entitlement to payment. Do not begin substantial work on the assumption that it will be accepted. Any fee, deadline, rights arrangement, exclusivity, editing process or other commercial term must be agreed explicitly in writing before work proceeds.
Editing, attribution and publication
Accepted material may be edited for accuracy, clarity, structure, length, style, accessibility and consistency with the publication’s standards. Material changes to the meaning of a contributor’s argument should be handled carefully. Editors may request clarification or supporting evidence and may remove unsupported or inappropriate claims. Contributors should respond to editorial questions accurately and promptly where an agreed process exists.
Bylines and biographies should reflect the contributor’s identity and relevant experience accurately. Any author biography or organisational affiliation may be edited for length and clarity without misrepresenting credentials. Publication does not guarantee that a piece will remain unchanged indefinitely; material may be updated or corrected when circumstances require it.
Corrections and ongoing responsibility
Contributors should notify the publication if they discover a material error in work they have supplied, or if new evidence substantially changes its interpretation. We may correct, clarify, update or, in serious cases, remove material where appropriate. We do not promise that every disagreement will result in a change, but credible evidence should be considered on its merits.
These guidelines may be updated as the publication’s editorial processes develop. They describe the standards expected of prospective contributors and should not be interpreted as a guarantee that every submission will be reviewed by an independent technical panel or external specialist.