Working on a "Spike"
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- documentation
Research direction
Start by reviewing the repository’s existing contributing documentation and the example in dwyl/learn-nightwatch issue 8. Add a separate section explaining what a spike is, how to timebox and document one, and what to do with the findings; confirm that the guidance fits the surrounding contribution workflow.
Written by the indexing model from the issue text.
Description
I think this deserves a separate section as:
a) Less experienced developers don't tend to know what a spike is
b) It is, in my experience, something which has been treated with very little process and as a result, the information resulting from it is often not useable.
What?
A spike is a limited period of time (often between half a day and two days) during which you try a number of different methods to solve a problem, in order to determine what the best solution is. The code that you write during this time is not used directly in the project, but the lessons you learn are.
How to perform one?
- Timebox your spike
- Determine what the different methods you will try are
- Start researching and trying these approaches outside of the main body of code
- Document all of your steps as you go along - this is crucial, not only are you more likely to actually keep track of your findings this way, but you are also providing a very valuable resource of the journey you've taken for future developers who encounter the same issues
- A good example of doing this is https://github.com/dwyl/learn-nightwatch/issues/8
- Determine which approach you will follow, throw the code away and open an issue in your project's repo so that you can begin the implementation.
- Dominant language
- No language data
- Stars
- 92
- Forks
- 9
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dwyl/contributing
-
bug chore starter
Difficulty 1/5 Under an hour Newbie friendliness 38/100
dwyl/contributing#119 · 1 reaction ·
-
enhancement starter
Difficulty 1/5 1-3 hours Newbie friendliness 35/100
dwyl/contributing#118 · 1 reaction ·
-
discuss enhancement
Difficulty 4/5 3-5 days Newbie friendliness 25/100
dwyl/contributing#113 · 2 reactions ·
-
discuss enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
dwyl/contributing#112 · 1 reaction ·
-
Draft Pull Requests!Opendiscuss enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 42/100
dwyl/contributing#111 · 2 comments · 3 reactions ·
All issues in dwyl/contributing
Similar issues
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
enhancement priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
briandconnelly/amicus#351 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
nginxinc/nginx-hugo-theme#498 ·
-
track: content
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
0xAndersen/witness-log#10 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100
w3c/csswg-drafts#14589 ·
Maintainers usually reply within 1 day