You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
*[Modifying an existing docstring in `src/`](#modifying-an-existing-docstring-in--src--)
9
+
*[Adding a new docstring to `src/`](#adding-a-new-docstring-to--src--)
10
+
*[Doctests](#doctests)
11
+
*[Integration with exisiting API](#integration-with-exisiting-api)
12
+
*[Contributing](#contributing)
13
+
*[Style Guidelines](#style-guidelines)
14
+
*[Git Recommendations For Pull Requests](#git-recommendations-for-pull-requests)
15
+
5
16
## Overview
6
17
Thank you for thinking about making contributions to Survey.jl!
7
18
We aim to keep consistency in contribution guidelines to DataFrames.jl, which is the main upstream dependency for the project.
@@ -16,6 +27,46 @@ Reading through the ColPrac guide for collaborative practices is highly recommen
16
27
(`Pkg.add(name="Survey", rev="main")`) is a good gut check and can streamline the process,
17
28
along with including the first two lines of output from `versioninfo()`
18
29
30
+
## Setting up development workflow
31
+
32
+
Below tutorial uses Windows Subsystem for Linux (WSL) and VSCode. Linux/MacOS/BSD can ignore WSL specific steps.
33
+
34
+
1. Install Ubuntu on WSL from the [Ubuntu website](https://ubuntu.com/wsl) or the Microsoft Store
35
+
2. Create a fork of the [Survey.jl repository](https://github.com/xKDR/Survey.jl). You will only be ever working on this fork, and submitting Pull Requests to the main repo.
36
+
3. Copy the SSH link from your fork by clicking the green `<> Code` icon and then `SSH`.
37
+
- You must already have SSH setup for this to work. If you don't, look up a tutorial on how to clone a github repository using SSH.
9. In the WSL terminal (not Julia REPL), run `julia dev/test.jl`
64
+
✅ If you get no errors, your setup is now complete !
65
+
66
+
You can keep working in the `dev` folder, which is .gitignored.
67
+
Once you have working code and tests, you can move them to the appropriate folders, commit, push, and submit a Pull Request.
68
+
Make sure to read the rest of this document so you can learn the best practices and guidelines for this project.
69
+
19
70
## Modifying an existing docstring in `src/`
20
71
21
72
All docstrings are written inline above the methods or types they are associated with and can
@@ -94,7 +145,7 @@ This way you are modifying as little as possible of previously written code, and
94
145
* If you want to propose a new functionality it is strongly recommended to open an issue first and reach a decision on the final design.
95
146
Then a pull request serves an implementation of the agreed way how things should work.
96
147
* If you are a new contributor and would like to get a guidance on what area
97
-
you could focus your first PR please do not hesitate to ask and JuliaData members
148
+
you could focus your first PR please do not hesitate to ask community members
98
149
will help you with picking a topic matching your experience.
99
150
* Feel free to open, or comment on, an issue and solicit feedback early on,
100
151
especially if you're unsure about aligning with design goals and direction,
@@ -104,22 +155,15 @@ This way you are modifying as little as possible of previously written code, and
104
155
* Aim for atomic commits, if possible, e.g. `change 'foo' behavior like so` &
105
156
`'bar' handles such and such corner case`,
106
157
rather than `update 'foo' and 'bar'` & `fix typo` & `fix 'bar' better`.
107
-
* Pull requests are tested against release and development branches of Julia,
108
-
so using `Pkg.test("DataFrames")` as you develop can be helpful.
158
+
* Pull requests are tested against release branches of Julia,
159
+
so using `Pkg.test("Survey")` as you develop can be helpful.
109
160
* The style guidelines outlined below are not the personal style of most contributors,
110
161
but for consistency throughout the project, we've adopted them.
111
-
* It is recommended to disable GitHub Actions on your fork; check Settings > Actions.
112
162
* If a PR adds a new exported name then make sure to add a docstring for it and
113
163
add a reference to it in the documentation.
114
164
* A PR with breaking changes should have `[BREAKING]` as a first part of its name.
115
-
* If a PR changes or adds functionality please update NEWS.md file accordingly as
116
-
a part of the PR (along with the link to the PR); please do not add entries
117
-
to NEWS.md for changes that are bug fixes or are not user visible, such as
118
-
adding tests, updating documentation or improving code layout.
119
-
* If you make a PR please try to avoid pushing many small commits to GitHub in
120
-
a sequence as each such commit triggers a separate CI job, which takes over
121
-
an hour. This has a consequence of making other PRs in packages from the JuliaData
122
-
ecosystem wait for such CI jobs to finish as hey share a common pool of CI resources.
165
+
* A PR which is still draft or work in progress should have `WIP:` as a first part of its name.
166
+
* If you make a PR please try to avoid pushing many small commits to GitHub in a sequence as each such commit triggers a separate CI job, which takes compuational time, and not a good use of the small pool of CI resources.
The constructor has the same arguments as [`SurveyDesign`](@ref). The only additional argument is `replicate_weights`, which can
166
+
be of one of the following types.
167
+
168
+
- `Vector{Symbol}`: In this case, each `Symbol` in the vector should represent a column of `data` containing the replicate weights.
169
+
- `UnitIndex{Int}`: For instance, this could be UnitRange(5:10). This will mean that the replicate weights are contained in columns 5 through 10.
170
+
- `Regex`: In this case, all the columns of `data` which match this `Regex` will be treated as the columns containing the replicate weights.
171
+
172
+
All the columns containing the replicate weights will be renamed to the form `replicate_i`, where `i` ranges from 1 to the number of columns containing the replicate weights.
173
+
174
+
# Examples
175
+
176
+
Here is an example where the [`bootweights`](@ref) function is used to create a `ReplicateDesign`.
If the replicate weights are given to us already, then we can directly pass them to the `ReplicateDesign` constructor. For instance, in
199
+
the above example, suppose we had the `bootstrat` data as a CSV file (for this example, we also rename the columns containing the replicate weights to the form `r_i`).
200
+
201
+
```jldoctest replicate-design
202
+
julia> using CSV;
203
+
204
+
julia> DataFrames.rename!(bootstrat.data, ["replicate_"*string(index) => "r_"*string(index) for index in 1:1000]);
0 commit comments