Fetching the latest programs, projects, and workspace data.

Tremor supports a number of other systems to connect one, yet one of the most widespread API's in the cloud world (S3) isn't yet supported. This is a chance to shine and build something many users will enjoy.
Showing 5 of 13 projects. Click any project card for scope, mentors, and proposal studio.
Tremor uses its own language for pluggable user defined functionality. The language interconnects internal operators via the connect statement and the select statement. Currently, neither select nor connect verifies that the operator port of the receiving or the sending part is correct ( exists, and is an expected type ) - this can lead to silent or confusing errors. User experience is super important to tremor, so that is a solution state we’re not happy with. The goal of this mentorship is to add validation and provide targeted hygienic errors to users that are trivial to diagnose and resolve as this will massively improve user experience.
Tremor is an event processing system that can - among other things - process logs and metrics. Currently, Tremor uses log4rs to handle its own logging. We would like tremor to have a facility to handle its logs through its own pipelines (similar to the pluggable metrics experience). A starting point could be a sink for log4rs, which could then be replaced completely, making log4rs an optional output.
Description: Connectors are tremors interface to the outside world, they allow us to integrate with third-party systems. Currently, tremor only has a limited set of connectors for databases, we support s3 and google cloud storage for object stores, and have a k/v connector that offers a simple integrated key-value store. While this is a good starting point interfacing with more databases will make tremor easier to use for our end users. The primary target will be integrating with Yandex Clickhouse.
Enhance tremor with connectors for the Google Cloud Platform
As an early stage project we’ve biased in favour of documenting the essentials and getting content in place as fast as possible. This has worked well but a side-effect is 3 or 4 different sources of content ( www, docs, rfcs and courseware ). In concert with CNCF technical writing and learning best practices use your UX/web design and technical writing expertise for tremor where we as a team are unskilled - make our content awesome and the user experience exceptional. These are some improvements we did think of, but these are neither complete nor required, more suggestions are welcome: - Unify the different content forms under a single consolidated theme and design - Ease of navigation ( breadcrumbs ) - Preserve markdown for data entry ( we’re programmers ) and keep design separate ( we’re not designers and find this stuff super hard ) - A clean, easy to navigate theme with a focus on user experience - Well integrated with our CI and doc generation tooling ( think gitops for docs and content ) This task would suit a candidate who is interested in `full stack` engineering and the complete software development lifecycle with a specific focus or interest in engineering documentation, web design and communicating well designed content to others with a good user experience - exploiting principles of good technical writing and web design of content management systems for technical content consumers.