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
Copy file name to clipboardExpand all lines: community/events/intro.md
+5-3Lines changed: 5 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -7,11 +7,12 @@ pyOpensci staff regularly attend community meetings (e.g. SciPy meeting, PyCon U
7
7
In these instances, asynchronous communication and sharing of documents in an organized way is critical.
8
8
9
9
### Event documents
10
+
10
11
For every meeting, pyOpenSci staff should create a Google Drive folder, located in our pyos-shared drive, where meeting documents will be stored. These documents may include talk and workshop proposals, attendee signup lists, graphics used in social media and outreach posts and more content related to the event.
11
12
12
-
Before an event, pyOpenSci staff will make sure this folder is shared and supporting documents are added to it. Often the folder will be created prior to the event to store talk, Bof (birds of a feather), townhall and workshop proposals.
13
+
Before an event, pyOpenSci staff will make sure this folder is shared and supporting documents are added to it. Often the folder will be created prior to the event to store talk, BoF (birds of a feather), Townhall and workshop proposals.
13
14
14
-
:::{admonition} Team checkin prior to an event
15
+
:::{admonition} Team check in prior to an event
15
16
:class: note
16
17
17
18
Staff should also have a short check-in prior to an event to ensure that all documents, and elements needed for the event, are shared in the right place, appropriate permissions are granted, remote support needs for the event are clarified, etc.
@@ -40,7 +41,8 @@ Prior to an in-person sprint, the following items should be created:
40
41
41
42
1. A template "sign up" form, created in HubSpot and shared via a bit.ly shortlink, with data fields that we collect from participants. This allows us to track who attends and event and to followup with them after (if they wish to have communication with us after)
42
43
1. A tabletop “card” that says pyOpenSci. You will need 2-3 cards on hand for any event in case participants are spread across a few tables. This card will be important for events like sprints, workshops and open spaces where pyOpenSci has one or more tables in a large room. It will signal to contributors that we are there and help people quickly find us.
43
-
* The card should have a qr code that is dynamic (so we can update the url that it points to and reuse the cards). This will allow us to have participants scan the code using their phones, and add their names as participants in the event. Following the event we can then send a thank you message to each participant using MailChimp or HubSpot.
44
+
45
+
* The card should have a qr code that is dynamic (so we can update the url that it points to and reuse the cards). This will allow us to have participants scan the code using their phones, and add their names as participants in the event. Following the event we can then send a thank you message to each participant using MailChimp or HubSpot.
44
46
45
47
:::{todo}
46
48
will this work for events as we will want an event name associated with it but it would be annoying to make a new card for every event? UNLESS we make a bunch at once for all events for the year?
Copy file name to clipboardExpand all lines: organization/internal-documentation.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -8,6 +8,6 @@ Google Drive, a part of the pyOpenSci Google Workspace plan, is where all pyOpen
8
8
* slides that support talks and presentations
9
9
* and more.
10
10
11
-
As a pyOpenSci staff member, you should store any documents related to pyOpenSci in the **pyos-shared** Google Shared Drive. Storing documents in the **pyos-shared** drive ensures that all pyOpenSci employees can access, edit, and use these documents. Storing these documents in the shared drive also supports program task redundancy, as the document's owner is the organization in that drive rather than an individual user. Storing documents in a shared drive owned by the organization helps pyOpenSci staff jump in and help another staff person in the event of a needed but unplanned absence (e.g., a medical emergency or an unexpected family issue).
11
+
As a pyOpenSci staff member, you should store any documents related to pyOpenSci in the **pyos-shared** Google Shared Drive. Storing documents in the **pyos-shared** drive ensures that all pyOpenSci employees can access, edit, and use these documents. Storing these documents in the shared drive also supports program task redundancy, as the document's owner is the organization in that drive rather than an individual user. Storing documents in a shared drive owned by the organization helps pyOpenSci staff jump in and help another staff person in the event of a needed but unplanned absence (e.g., a medical emergency or an unexpected family issue).
12
12
13
13
Employees can save personal documents such as 1-on-1 agendas and notes, personal notes, and other information that does not need to be shared at the organizational level in their personal drive.
4. Review process -- where should the review template live to make it easier for people to find?
28
-
1. Create issues in package repo ala JOSS or do it all in the software-review repo ala rOpenSci? https://github.com/pyOpenSci/dev_guide/issues/17
29
-
2. Currently sits: https://www.pyopensci.org/dev_guide/appendices/templates.html#review-template
27
+
1. Create issues in package repo ala JOSS or do it all in the software-review repo ala rOpenSci? <https://github.com/pyOpenSci/dev_guide/issues/17>
28
+
2. Currently sits: <https://www.pyopensci.org/dev_guide/appendices/templates.html#review-template>
30
29
* NEIL -- didn't have an issue finding the template. he'd like to see it in the email AND the comment for the review ... so maybe the editor should do this OR Whedon the bot could do this??
31
30
* also in the guidances for reviewers and authors...
32
-
*https://pyopensci.discourse.group/
33
-
* Luiz: maybe create a review issue template, so the checklist doesn't need to be copied? example: https://github.com/datrs/hypercore/tree/master/.github/ISSUE_TEMPLATE
31
+
*<https://pyopensci.discourse.group/>
32
+
* Luiz: maybe create a review issue template, so the checklist doesn't need to be copied? example: <https://github.com/datrs/hypercore/tree/master/.github/ISSUE_TEMPLATE>
34
33
* have one template for review, another for pre-review, and submissions
35
34
* Kylen: We have issue templates for submission and pre-submission. Haven't made one for review because they are comments on existing issues, not new issues by themselves. Is there the option to create a comment template?
36
35
* Luiz: I don't think there is... sorry, I was thinking on the JOSS structure (where there is a pre-review and a review issue)
*[rOpenSci Requirements based on a discussion with Arfon](https://hackmd.io/KxM9HK-eSo-x2nkTOSBeow)
41
40
*[Notes from meeting with Arfon](https://hackmd.io/Vw2tyNxZQ5-PItkQFTZqhA)
42
41
* NOAM takes the floor:
43
-
*Ropensci is talking with Arfon as well. JOSS requires a zenodo doi, they want to ensure the version of the package is accepted is linked to a DOI. DOI's are relevant for JOSS but not explicitly tracked in the ropensci process. The DOI for the final version in the review is used for JOSS.
44
-
*ropensci has a diagnostic package that they use to provide some feedback and it's run on submission in a standardized envt... and the bot will be able to spit out results
45
-
*They've had a few scenarios where authors have requested an updated review. It's not practical... because it's resource intensive...
46
-
*Current whedon functionality
47
-
** one we get feedback on the bot, send all of the input to karthik, arfon and noam
48
-
*Linsdey -- dashboard with whedon -- allows them to look at editor and reviewer loads, etc etc... that is super helpful. JOSS backend might be a google sheet.
42
+
* Ropensci is talking with Arfon as well. JOSS requires a zenodo doi, they want to ensure the version of the package is accepted is linked to a DOI. DOI's are relevant for JOSS but not explicitly tracked in the ropensci process. The DOI for the final version in the review is used for JOSS.
43
+
* ropensci has a diagnostic package that they use to provide some feedback and it's run on submission in a standardized envt... and the bot will be able to spit out results
44
+
* They've had a few scenarios where authors have requested an updated review. It's not practical... because it's resource intensive...
45
+
* Current whedon functionality
46
+
** one we get feedback on the bot, send all of the input to karthik, arfon and noam
47
+
* Linsdey -- dashboard with whedon -- allows them to look at editor and reviewer loads, etc etc... that is super helpful. JOSS backend might be a google sheet.
49
48
50
49
## JOSS vs rOpenSci Review process
50
+
51
51
* JOSS process follows PLOS -- minimal requirements whereas rOpenSci is more intense process.
52
52
* LEO: JOSS for example doesn't have (automated) test requirements. it's valuable for us to be more strict
53
53
* LUIZ: especially considering curating packages...we want to give our stamp of approval
54
54
55
55
## Funding Opportunity support via rOpenSci
56
56
57
-
* Ropensci applied for funding -- to support methods focused packages
58
-
* aggregate, automate and document current ropensci processes
59
-
* how to create a review community
60
-
* automation
61
-
* creating reviewer databases
62
-
* Send reminders, etc - create tools to handle this and make it easy for other groups to adopt
63
-
* Write standards for software in a way that can be tested
* Levi Wolf (of PySAL, Contextily, and Geopandas) volunteered to be a future reviewer
85
85
8. New pre-submission inquiry! [pacifica](https://github.com/pyOpenSci/software-review/issues/2)
86
86
* Please provide your feedback on whether we should encourage a submission in this document (be mindful this document is public so if you are not comfortable with that please email us or speak up during our meeting!!)
87
-
* More info might be helpful here - the provided link is https://github.com/pacifica but, that has many repos. It might be easier to review if we are reviewing one repository, rather than many repositories.
88
-
* The core repository is a Docker compose pipeline (https://github.com/pacifica/pacifica) composed of submodules, each of which is a package - maybe this would be hard to review?
87
+
* More info might be helpful here - the provided link is <https://github.com/pacifica> but, that has many repos. It might be easier to review if we are reviewing one repository, rather than many repositories.
88
+
* The core repository is a Docker compose pipeline (<https://github.com/pacifica/pacifica>) composed of submodules, each of which is a package - maybe this would be hard to review?
89
89
* rOpenSci has onboarded suites of tools but also didn't accept a tool that wrapped around another language... given that would be outside of our expertise..
90
90
* a shiny app would not be accepted nor a larger system
91
-
*LUIZ: pyopensci is more for lego blocks vs .. do we want to curate small packages or packages that can work together...
92
-
*NOAM: there are different ways that a python "package" could be presented. we might want to define what a package is and means...
93
-
*LEO: for python there is a standard packaging schema but you could have say a web app... that has a different structure. PAcifica does seem to have a set of a few sub packages that have standard python packages..
94
-
*Luiz: would we consider jupyter for example...
95
-
*NEIL: we need to really define the scope of what creates a package and what we will review... perhaps we need something that refines the scope, the type of package, how it sits within a larger envt, etc...
91
+
* LUIZ: pyOpenSci is more for lego blocks vs .. do we want to curate small packages or packages that can work together...
92
+
* NOAM: there are different ways that a python "package" could be presented. we might want to define what a package is and means...
93
+
* LEO: for python there is a standard packaging schema but you could have say a web app... that has a different structure. PAcifica does seem to have a set of a few sub packages that have standard python packages..
94
+
* Luiz: would we consider jupyter for example...
95
+
* NEIL: we need to really define the scope of what creates a package and what we will review... perhaps we need something that refines the scope, the type of package, how it sits within a larger envt, etc...
96
96
97
97
TODO: how do we dfeine the scope of a what a package is....
98
98
99
-
9. Development glossary -- anyone want to contribute and where should we place it? https://github.com/pyOpenSci/dev_guide/issues/8
99
+
9. Development glossary -- anyone want to contribute and where should we place it? <https://github.com/pyOpenSci/dev_guide/issues/8>
100
100
101
101
10. PyCon open space feedback (Luiz)
102
-
- a quickstart (condensed guide)
103
-
- nanopore interested in contributing software, might be a good venue
104
-
- EBI (European Bioinformatics Institute) has lots of open source packages, but not much marketing
105
-
- .org website feedback
106
-
- Link discourse to the main page of pyopensci.org: https://pyopensci.discourse.group/
107
-
- .org website -- too overwhelming for someone new??
108
-
109
-
- accept submissions to pyOpenSci that are already JOSS papers?
102
+
* a quickstart (condensed guide)
103
+
* nanopore interested in contributing software, might be a good venue
104
+
* EBI (European Bioinformatics Institute) has lots of open source packages, but not much marketing
105
+
* .org website feedback
106
+
* Link discourse to the main page of pyopensci.org: <https://pyopensci.discourse.group/>
107
+
* .org website -- too overwhelming for someone new??
108
+
109
+
* accept submissions to pyOpenSci that are already JOSS papers?
110
110
* another fast track?
111
111
* makes sense for the "curated packages" approach
112
-
- requirements?
113
-
- code coverage? (no)
114
-
- ropensci doesn't have a % coverage but automated testing and CI is required. The code coverage is required to be reported. if the coverage is low, you have to justify it to the editor...
115
-
- stable versions (semantic versioning?)
116
-
- Link to current reqs: https://www.pyopensci.org/dev_guide/packaging/packaging_guide.html#overview
117
-
112
+
* requirements?
113
+
* code coverage? (no)
114
+
* ropensci doesn't have a % coverage but automated testing and CI is required. The code coverage is required to be reported. if the coverage is low, you have to justify it to the editor...
115
+
* stable versions (semantic versioning?)
116
+
* Link to current reqs: <https://www.pyopensci.org/dev_guide/packaging/packaging_guide.html#overview>
118
117
119
118
## To Do Takeaways - For Everyone
119
+
120
120
1. Please review the whedon bot requirements and give us feedback
121
121
2. email to arfon, karthik and noam about whatever our requirements end up being for whedon.
122
122
3. Please review the pacifica submission and provide your input
Copy file name to clipboardExpand all lines: reference/meeting-notes/2019/2019-05-30-notes.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -123,7 +123,7 @@ other option - code for science and society -- but neil things they are more foc
123
123
124
124
1. Updates: 6 packages in the submission queue!
125
125
126
-
*[pacifica](https://github.com/pyOpenSci/software-review/issues/2) -- we need to make a decision on it. it's an envt / set of tools. So the question at hand is DOES pyopensci accept these types of submissions? Or do we prefer individual submissions at this point. It would be good to decide this week
126
+
*[pacifica](https://github.com/pyOpenSci/software-review/issues/2) -- we need to make a decision on it. it's an envt / set of tools. So the question at hand is DOES pyOpenSci accept these types of submissions? Or do we prefer individual submissions at this point. It would be good to decide this week
127
127
* Luiz: I think it's a good submission in the future, but it's a really hard submission at the moment (due to complexity).
0 commit comments