DEV Community

Cover image for Getting Your Tasks Accepted on Stellify: Think Patterns, Not Features
Matthew Anderson
Matthew Anderson

Posted on

Getting Your Tasks Accepted on Stellify: Think Patterns, Not Features

How to Formulate Abstract and Granular Tasks that will be accepted in Stellify

Creating tasks for our shared codebase requires thinking beyond specific features to the underlying patterns and behaviours that make them work. This guide will help you formulate tasks that are abstract, granular, and reusable across multiple contexts and therefore likely to be accepted when submitted.

The Core Principle

Think patterns, not implementations. Instead of creating tasks for specific features, identify the fundamental behaviors and interactions that can be applied universally.

❌ Avoid: Implementation-Specific Tasks

  • "OTP Password Input"
  • "Shopping Cart Checkout Button"
  • "User Profile Avatar Upload"
  • "Blog Post Comment Section"

✅ Prefer: Abstract Pattern Tasks

  • "Contiguous inputs that switch focus upon valid input"
  • "State-aware action button with loading and confirmation states"
  • "Drag-and-drop file upload with preview and validation"
  • "Nested comment thread with collapsible replies"

Why Abstract and Granular?

1. Maximum Reusability

An abstract "contiguous input" component can be used for:

  • OTP verification
  • Credit card number entry
  • Serial number input
  • PIN codes
  • Date/time pickers

2. Clear Scope

Granular tasks have well-defined boundaries, making them:

  • Easier to estimate
  • Less prone to scope creep
  • More testable
  • Simpler to review

3. Composable Architecture

Small, focused components can be combined to create complex features:

Modal + Form Validation + File Upload = Document Upload Dialog
Data Table + Infinite Scroll + Search Filter = Advanced User List
Enter fullscreen mode Exit fullscreen mode

The GRASP Framework

Use this framework to evaluate and refine your tasks:

Granular

  • Can be completed in 1-8 hours
  • Has a single, well-defined responsibility
  • Doesn't depend on other incomplete features

Reusable

  • Solves a pattern, not a specific case
  • Can be applied in multiple contexts
  • Uses generic naming and interfaces

Abstract

  • Focuses on behavior, not content
  • Separates form from function
  • Avoids domain-specific terminology

Standalone

  • Can be developed independently
  • Has clear inputs and outputs
  • Doesn't require external dependencies

Pattern-based

  • Represents a common UI/UX pattern
  • Solves a recurring problem
  • Follows established conventions

Task Formulation Examples

1. Form Components

❌ Implementation-Specific ✅ Abstract Pattern
"Registration form validation" "Real-time form field validation with configurable rules"
"Login form with remember me" "Form with persistent state option"
"Contact form submission" "Form submission with loading states and error handling"

2. Data Display

❌ Implementation-Specific ✅ Abstract Pattern
"User table with sorting" "Data table with configurable column sorting"
"Product grid with filters" "Card grid with dynamic filtering"
"Order history pagination" "Infinite scroll with loading indicators"

3. Interactions

❌ Implementation-Specific ✅ Abstract Pattern
"Add to cart animation" "Visual feedback for state change actions"
"Delete user confirmation" "Destructive action confirmation dialog"
"Save draft functionality" "Auto-save with conflict resolution"

4. Navigation

❌ Implementation-Specific ✅ Abstract Pattern
"E-commerce breadcrumbs" "Hierarchical navigation with current state indication"
"Admin sidebar menu" "Collapsible navigation with nested items"
"Product category tabs" "Tab navigation with lazy-loaded content"

Task Structure Template

Use this template to structure your abstract tasks:

**Title:** [Behavior] + [Context] + [Key Feature]
Example: "Progressive disclosure accordion with smooth animations"

**Description:**
A brief explanation of the pattern and its purpose.

**Acceptance Criteria:**
- [ ] Functional requirement 1
- [ ] Functional requirement 2
- [ ] Visual/interaction requirement
- [ ] Accessibility requirement
- [ ] Performance requirement

**Configuration Options:**
List the props/settings that make it reusable:
- Animation duration
- Expand behavior (single vs multiple)
- Default state (expanded/collapsed)

**Use Cases:**
- FAQ sections
- Settings panels
- Product specifications
- Help documentation

**Technical Requirements:**
- Framework/library constraints
- Browser support requirements
- Performance benchmarks
Enter fullscreen mode Exit fullscreen mode

Red Flags to Avoid

🚨 Too Specific

  • Contains business logic or domain rules
  • References specific data models
  • Includes branding or styling details
  • Tied to particular user roles

🚨 Too Broad

  • Combines multiple patterns
  • Requires more than 8 hours
  • Has vague acceptance criteria
  • Depends on incomplete features

🚨 Not Reusable

  • Solves a one-time problem
  • Hard-codes specific values
  • Cannot be configured
  • Too narrow in scope

Quality Checklist

Before submitting a task, verify it meets these criteria:

  • [ ] Abstract: Focuses on behavior, not specific implementation
  • [ ] Granular: Can be completed in a single focused session
  • [ ] Reusable: Applicable in multiple contexts
  • [ ] Well-defined: Clear boundaries and acceptance criteria
  • [ ] Configurable: Accepts parameters for customization
  • [ ] Pattern-based: Represents a common UI/UX pattern
  • [ ] Technology-agnostic: Not tied to specific frameworks (where possible)
  • [ ] Accessible: Includes accessibility considerations
  • [ ] Testable: Can be unit and integration tested

Example: Good vs. Bad Task

❌ Bad Task

Title: "User Profile Picture Upload"
Description: Add functionality for users to upload and crop their profile pictures in the account settings page.

Problems: Too specific, tied to user domain, single-use

✅ Good Task

Title: "Image upload with crop and preview functionality"
Description: Create a reusable component that allows users to select, crop, and preview images before upload.

Acceptance Criteria:

  • [ ] File selection with drag-and-drop support
  • [ ] Image cropping with adjustable aspect ratio
  • [ ] Real-time preview of cropped result
  • [ ] Validation for file type and size
  • [ ] Progress indicator during upload
  • [ ] Error handling for failed uploads

Configuration Options:

  • Accepted file types
  • Maximum file size
  • Crop aspect ratios
  • Preview dimensions
  • Upload endpoint

Use Cases:

  • Profile pictures
  • Product images
  • Blog post headers
  • Document thumbnails

Benefits of This Approach

  1. Faster Development: Reusable components reduce duplicate work
  2. Consistent UX: Similar patterns behave the same way
  3. Easier Maintenance: Changes to a pattern update all implementations
  4. Better Testing: Abstract components can be thoroughly tested
  5. Clear Architecture: System is built from well-defined building blocks
  6. Easier Onboarding: New developers learn patterns, not specific features

Getting Started

  1. Identify Patterns: Look at existing features and extract common behaviours
  2. Start Small: Begin with simple, well-understood patterns
  3. Document Use Cases: Show how the abstract component applies to real scenarios
  4. Iterate: Refine based on actual usage and feedback
  5. Build a Library: Create a collection of these abstract patterns

Remember: The goal is to build a codebase of reusable behaviors that can be combined to create any feature quickly and consistently.

We look forward to reviewing the tasks you submit and even more so to building the functionality! See you at Stellify!

Top comments (0)