More static pages

This commit is contained in:
Asaf Gartner 2021-05-04 18:14:30 +03:00
parent 4723eec3b6
commit dca101fd20
4 changed files with 147 additions and 15 deletions

View File

@ -0,0 +1,36 @@
{{ template "base.html" . }}
{{ define "content" }}
<div class="content-block">
<div class="description mw7 ph3 ph0-ns">
<p>The Handmade Network provides a place for project owners such as yourself to showcase and record the development of their projects, and for users to discover, follow and discuss these projects. This Monthly Update Policy applies to your project if it doesnt fit into a category listed under “When the Monthly Update Policy Doesnt Apply” below, and is intended to encourage development and guard against your active or complete project having to share web space with abandoned ones.</p>
<h2>What Constitutes an Update</h2>
<p>Outlined are the ways a project owner, or a well-meaning member of the projects community, may contribute to a monthly update. Note that updates must be made once per calendar month, by the last day of the month — not one month since the last update.</p>
<h3>Blog Post</h3>
<p>The most straightforward way to update the community with your progress is with a simple blog post within the network. The length of the post is not measured, as the network understands an individual may have difficult months. Therefore, anything in the spectrum of a quick message saying you had no progress, to a summary of a chat discussion, all the way up to a full-blown detailed development log would be considered a monthly update. Even with posts detailing your inability to work for a month, looking back at your own development history is an important exercise.</p>
<h3>Forum Activity</h3>
<p>Any activity in your projects forum would satisfy the monthly update policy. This includes contributions to any forum discussions from you as the project owner and from members of the community.</p>
<h3>Link to External Update</h3>
<p>YouTube videos, GitHub / GitLab repository links (e.g. to a recent commit), Reddit thread, Twitter threads discussing the projects current state, your own personal blog posts, are a few examples of what would work here. Such updates must be linked somewhere in your project page, blog, or forums in order to qualify. As a reminder, having a hyperlink in to your external blog in your signature or profile links that visitors are expected to follow up on without further prompting from you doesnt count.</p>
<h2>When the Monthly Update Policy Doesnt Apply</h2>
<h3>Grace Period</h3>
<p>New projects are not required to provide updates until the month following their approval. For example, if a project is posted in the middle of March, they are not required to post any further updates for March the monthly update policy will go in effect for that project in April.</p>
<h3>Personal Circumstances</h3>
<p>If the developer foresees not being able to provide a timely update this month, or possibly even for a number of consecutive months, we invite them to post a short update on their project blog letting their audience know theyll be taking a leave of absence. A reason need not be supplied. Should you feel uncomfortable in doing so, an email to <a href="mailto:team@handmadedev.org">team@handmadedev.org</a> in private will let us flag the project as in hiatus and it will let us deflect incoming questions about the projects status in your stead.</p>
<p>Although a blog post explaining the leave of absence will suffice, such an e-mail is still appreciated, of course.</p>
<h3>Project Completion</h3>
<p>When the project owner is confident the project has entered a stage of completion, a stage of maintenance with no further features, or it has changed identity such that it is no longer considered the original project, the monthly update would no longer be necessary. Please advise us of this so that we may update the status of your project, both for our bookkeeping, and for the purposes of sorting projects by status.</p>
<h2>What happens if the Project is Inactive</h2>
<h3>First Strike</h3>
<p>If for any month there was no activity, without having notified the network, the project owner will receive an e-mail within the first week of the following month. No further action will be taken for that month.</p>
<h3>Second Strike and Beyond</h3>
<p>If for any subsequent month there is no activity, without having notified the network, the project will receive an e-mail within the first week of the following month and will be flagged as in-hiatus until activity resumes. This will always happen for any inactive month following the first strike of the year. At the start of a new year, the strikes are reset, applying the first one first.</p>
<p>The project, while in hiatus, will remain as part of the project listings but may be pushed down the list, and may not be considered as a featured project while in this status. If it was a featured project at the time of being flagged due to a strike, it will be removed from the featured list.</p>
<h3>Three Months Inactivity</h3>
<p>If the project has been in hiatus for three months, without having notified the network, it is considered dead and removed from the project listings. E-mail <a href="mailto:team@handmadedev.org">team@handmadedev.org</a> to re-instate it the first time this occurs.</p>
<p>The second time a project reaches this status, without having notified the network, it will be considered permanently dead. At this point, the project will need to be re-submitted.</p>
<h2>How to be Featured</h2>
<p>More active projects have a better chance at being noticed by members and staff alike. Popular projects are more likely to receive votes towards a monthly community featured-project slot, though community interest can be piqued even by small or new projects if the project is producing interesting content. Community-chosen featured-project slots make up to 3 of the possible highlighted projects -- there are also up to 3 staff-pick featured slots each month. The recipients of these slots are at the discretion of the site staff, but you can make your project shine by frequently and consistently reporting progress on your project and interacting with the community.</p>
</div>
</div>
{{ end }}

View File

@ -0,0 +1,90 @@
{{ template "base.html" . }}
{{ define "extrahead" }}
<style>
ol {
list-style-type: lower-roman;
}
ol ol {
list-style-type: lower-alpha;
}
</style>
{{ end }}
{{ define "content" }}
<div class="content-block">
<div class="description mw7 ph3 ph0-ns">
<p>At Handmade Network, we pride ourselves on being open to hosting all sorts of projects, from low level tools to games to conscientious web applications to innumerable other carefully crafted varieties of software. With this in mind, there are certain standards of content quality that we expect projects hosted on the site to meet, and certain characteristics that we believe projects should uphold in order to best contribute to the community of software development we are attempting to cultivate.</p>
<p>This document outlines these standards and characteristics as specifically as possible, allowing for exceptions both in favor and against project approval if unanticipated circumstances arise. All project approvals or rejections will be accompanied by a justification, and we expect to be held accountable if the provided justification is insufficiently backed by these guidelines.</p>
<h2>Content Quality</h2>
<p>A high-quality Handmade Network project submission will:</p>
<ol>
<li><strong>Have a relevant and informative blurb</strong> which gives those browsing project listings a basic idea of the project's purpose and value. The 'elevator pitch', if you will</li>
<li>
<p><strong>Have a thorough description</strong>, which will give visitors several vital pieces of information in understanding the project:</p>
<ol>
<li>The background / impetus for the projects creation</li>
<li>The project's short-term and long-term goals</li>
<li>The current status of the project</li>
<li>The road-map to reaching these goals, both short- and long-term</li>
</ol>
<p>Excellent descriptions will also make use of (BBCode) markup to make it easier for readers to scan for relevant information.</p>
</li>
<li>
<p><strong>Provide links to other relevant websites</strong> where visitors may find out more about project development or the current activity of the author(s).</p>
<p>Common examples:</p>
<ol>
<li>A YouTube channel where the author(s) showcase latest features or record development logs</li>
<li>An external project homepage where new development builds can be found</li>
<li>An external source-code hosting site where the project's source code is available</li>
<li>A social media page for the project or the author(s) showing development progress</li>
</ol>
</li>
<li>
<p><strong>Provide several screenshots showcasing the current state of project development</strong>, if the project is visually oriented. Examples:</p>
<ol>
<li>A project with a graphical user interface should show what a typical user will see when interacting with the running program</li>
<li>Same goes for command line tool with a curses-like TUI</li>
<li>A game or game engine should provide several screenshots to give visitors an idea of what makes it unique</li>
<li>Visually-oriented projects with support for multiple platforms should provide at least one screenshot of the project running on each platform</li>
</ol>
</li>
<li><strong>Where possible, provide current builds of the project</strong> that visitors can run to see the state of the project.</li>
<li><strong>Customize the project page with appropriate colors or background images</strong> to give the project a sense of visual identity.</li>
</ol>
<p>Providing as much information about your project as possible will help us decide whether it meets the qualifications listed below, and whether community members will be invested in your project's success.</p>
<h2>Acceptable Projects</h2>
<p>For us to be willing to approve a project on the site, it should:</p>
<ol>
<li><strong>Be a legitimate, unique, and original work.</strong> We unequivocally will not accept projects which are blatantly advertisements for unrelated websites or companies, projects which are indistinguishable from others on the site, projects which are incorrectly attributed to someone other than the actual creator.</li>
<li><strong>Have a meaningful amount of development work planned or completed above its dependencies, parent project, or previous incarnation.</strong> We will not accept projects which cannot prove themselves to be more than a thin layer of “glue code” above several libraries, or which are barely-modified forks of other projects.</li>
<li>
<p><strong>Be the development effort of an individual or small team, organization or company.</strong> We wish to keep the focus of this site on projects which highlight the inspiring work of small developers, projects which provide a high ratio of value-added to man-hours worked, and the exploration of software creation as a craft. We will refrain from defining “small” for the purposes of this guideline, and instead give examples of approvals and rejections:</p>
<ol>
<li>A commercial compression tool developed by a small team of 2-4 programmers and a few miscellaneous staff under the umbrella of an LLC would be approved.</li>
<li>A suite of productivity software developed by a large multinational corporation would be rejected, as it is not in line with the intended focus of the site, and such a corporation is likely already receiving widespread exposure elsewhere and may have their own extensive user community.</li>
<li>An existing, well-established open-source project with a contributor count at the time of submission in the thousands may be approved or rejected depending on other factors like the age of the project, the number of current contributors, the content to be provided on Handmade Network vs the project's homepage, and the current state of development of the project.</li>
</ol>
</li>
<li>
<p><strong>Enrich to the community</strong> by releasing finished projects for community members to use or purchase and providing regular updates that inform and educate community members. We heavily encourage activities such as:</p>
<ol>
<li>Writing or recording logs/articles explaining decisions/trade-offs made during development and their rationale, theory behind a piece of code, information discovered about an API or dependency.</li>
<li>Releasing demos, samples, or pre-release versions demonstrating the mechanics or evolution of a particular feature</li>
<li>Responding to questions about functionality in comments/forums.</li>
</ol>
<p>For more information on this, please see our <a href="/monthly-update-policy">Monthly Update Policy</a> requirements and suggestions.</p>
</li>
<li><strong>Have a clear, achievable goal or set of goals and provide lasting value to its intended audience.</strong> We want to discourage projects from falling into development limbo and slowly dying off. We also want to encourage project owners to support their projects past release, so that they might have continuing usefulness as the dependencies and platforms they rely on continue to develop.</p>
</ol>
<p>Additionally, there are some criteria that we guarantee will <strong>not</strong> be considered in approving or rejecting a project:</p>
<ol>
<li><strong>Implementation language.</strong> A language is merely a tool, and worthwhile software can be created in any language or environment.</li>
<li><strong>Use (or not) of libraries.</strong> While we are supportive of efforts to develop software that makes minimal use of libraries, and to write code that supplants existing libraries, this is by no means a requirement of projects hosted on the site. We merely ask, as stated above, that projects perform some significant work above that which its dependencies perform on their own.</li>
<li><strong>License, monetization, and source-code provision.</strong> We do not require projects be open-source, free software, etc. While we are very supportive of these movements and the principles behind them, we also understand the need to make a living off of development work, and wish to make it possible for any project to contribute to and benefit from our software development community.</li>
</ol>
</div>
</div>
{{ end }}

View File

@ -95,21 +95,13 @@ func NewWebsiteRoutes(conn *pgxpool.Pool, perfCollector *perf.PerfCollector) htt
panic("route not implemented")
}
})
staticPages.GET("^/manifesto$", func(c *RequestContext) ResponseData {
return Manifesto(c)
})
staticPages.GET("^/about$", func(c *RequestContext) ResponseData {
return About(c)
})
staticPages.GET("^/code-of-conduct$", func(c *RequestContext) ResponseData {
return CodeOfConduct(c)
})
staticPages.GET("^/communication-guidelines$", func(c *RequestContext) ResponseData {
return CommunicationGuidelines(c)
})
staticPages.GET("^/contact$", func(c *RequestContext) ResponseData {
return ContactPage(c)
})
staticPages.GET("^/manifesto$", Manifesto)
staticPages.GET("^/about$", About)
staticPages.GET("^/code-of-conduct$", CodeOfConduct)
staticPages.GET("^/communication-guidelines$", CommunicationGuidelines)
staticPages.GET("^/contact$", ContactPage)
staticPages.GET("^/monthly-update-policy$", MonthlyUpdatePolicy)
staticPages.GET("^/project-guidelines$", ProjectSubmissionGuidelines)
mainRoutes.GET(`^/feed(/(?P<page>.+)?)?$`, Feed)

View File

@ -19,13 +19,27 @@ func CodeOfConduct(c *RequestContext) ResponseData {
res.WriteTemplate("code_of_conduct.html", getBaseData(c), c.Perf)
return res
}
func CommunicationGuidelines(c *RequestContext) ResponseData {
var res ResponseData
res.WriteTemplate("communication_guidelines.html", getBaseData(c), c.Perf)
return res
}
func ContactPage(c *RequestContext) ResponseData {
var res ResponseData
res.WriteTemplate("contact.html", getBaseData(c), c.Perf)
return res
}
func MonthlyUpdatePolicy(c *RequestContext) ResponseData {
var res ResponseData
res.WriteTemplate("monthly_update_policy.html", getBaseData(c), c.Perf)
return res
}
func ProjectSubmissionGuidelines(c *RequestContext) ResponseData {
var res ResponseData
res.WriteTemplate("project_submission_guidelines.html", getBaseData(c), c.Perf)
return res
}