Pushing Sanic Forward

142 views
Skip to first unread message

Adam Hopkins

unread,
Sep 4, 2018, 7:31:08 PM9/4/18
to Sanic Task Force
Let me first start this email by stating my utmost respect for everyone that has contributed to the Sanic project. It is (in my humble opinion) an outstanding example of the right balance of performance, features, usability, and flexibility that a framework should exhibit. There is, of course, still more work to be done.

I would like to follow this up by stating that I sincerely mean no harm or offense to anyone with this email. Please know that this comes from a place of wanting to see the Sanic project and community thrive for the benefit of the larger Python community.

Over the last several months, the PRs and issues seem to creating a feeling that the Sanic project is stalling. I speak mainly for myself, and my own observations of the community at large.

With that said, I would like to propose a solution to the development and release schedule backlog: We create a new "task force" that has the goal of outlining a plan to transition and create a Sanic organization.

The goal of the task force will be to determine logistical issues (who will create the repos), as well as the organizational issues (how often will releases be made, and who will decide what features to include) that need to be resolved and answered before the repo can be adopted by a community organization.

Anyone that has an interest in being on this task force should be accepted, and I invite each of you to add whomever you feel should be a part of this conversation. 

I am opting in part to have this discussion via email list because I feel it is somewhat inappropriate to have it on GitHub until a more clear picture of the future of this project has been made. If for no other reason, I would hate to scare away developers afraid of the project's future. On a practical level, you all are the people I identified as being interested in this conversation, and I thought it not worth bringing into the public forum if there was not a sufficient backing for it, especially amongst you.

---

Here are some initial thoughts I have for the task force.

I propose that we impose a deadline (October 31?) for the task force to have answers to these questions. Some form of accountability and deadline to begin giving the project a direction.

The task force should have a moderator whose job it is to make sure the conversation progresses, voices are heard, the discourse remains civil, and the deadline it met. His/her job is not to dictate the conversation, just facilitate it.

Here is a (non exhaustive) list of questions that I believe the task force should answer.

- Who will setup the organization and repos on GitHub?
- How will the backlog of issues be addressed/answered/cataloged?
- What repos will the organization be in charge of (for example, should testing and/or websockets remain in the core, or be removed to their own repos)?
- Community governance/contribution guidelines?
- Style guide
- Testing and performance standards (after all, gotta go fast)
- Build automation tooling for CI
- PR review and merge management
- Release note process
- Documentation process
- Release schedule 
- Feature proposal/enhancement acceptance 

---

I am excited and open to hearing your thoughts.

@channelcat, if you believe I am overstepping my boundaries here, please let me know.

Richard Kuesters

unread,
Sep 5, 2018, 10:35:19 AM9/5/18
to Sanic Task Force
Adam, first of all I would like to thank you for your effort on bringing this email with these concerns regarding Sanic, among an open invitation to all parts that want to do something more.

I really hope that we can organize ourselves and bring this forward for a happy ending - and a new beginning. I know I'm not a Sanic contributor (not by the lack of trying), but I've done some POCs with it, some plugins and have mangled its source code from top down to find a solution to some of my own problems.

Unfortunately, what I see is the lack of organization regarding most of the items described above. Some Sanic users that I know already dropped it in favor of another framework, some even creating new ones - sometimes with a huge effort that could have been done into Sanic. Well, I really don't mind (or find useless to discuss) what has been done and all the decisions taken in the past, but I'm really concerned about the future of Sanic.

Nevertheless, count me in.


Richard - @vltr

Adam Hopkins

unread,
Sep 5, 2018, 12:37:17 PM9/5/18
to sani...@googlegroups.com, Sanic Task Force
Richard,

I agree. This is about a way forward and moving sanic into the future. Glad to have you on board.

--
Adam Hopkins



Sep 5, 2018, 5:35 PM by rkue...@gmail.com:
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Michael Hill

unread,
Sep 6, 2018, 5:14:31 PM9/6/18
to Sanic Task Force
Hey Adam and Richard

Thank you so much for setting this up and putting time into Sanic.  I'm glad that there are maintainers like you who are super passionate about the project and are doing what it takes to help it achieve its final form.

I think the list you've made sounds great, and I'd also like to throw in that we should solidify the vision and core values for Sanic that can help keep everyone on the same page moving forward.

I've messaged the group of current maintainers to see what they think about the situation.  To be honest, I have not given them the time and resources they have been asking for, and I am not sure if they are worn out and still want to be a part of the project.  Give me a few days to collect everyone, and I'll be able to speak more to the action items you listed.

Adam Hopkins

unread,
Sep 6, 2018, 6:07:10 PM9/6/18
to Channelcat, Sanic Dev, Sanic Task Force
Michael,

That sounds fair and totally reasonable. Again, I definitely do not want to push the project in a way that you or any of the other maintainers are uncomfortable with. This is your baby and of the others sitting atop that commit chart.

As.for vision, I like that a lot. I just finished berating another "open source" project for their lack of vision and identity that lead them to making (in my opinion) a bad decision: 

https://discuss.dgraph.io/t/switching-dgraph-to-a-liberal-license-dgraph-blog/2411/25?u=ahopkins


I very much look forward to seeing that final form.... and updating requirements.txt to sanic==1.0. If I can be of help in that, I will.

--
Adam Hopkins



Sep 7, 2018, 12:14 AM by chann...@gmail.com:
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.

Richard Kuesters

unread,
Sep 7, 2018, 12:20:58 PM9/7/18
to Sanic Task Force
Thanks a lot, Michael!

I'm kind of eager to help on the Sanic project, but as Adam pointed out in the first e-mail there are a lot of things to be deal with the current state of the project. It is hard to tackle on a specific point or feature you have in mind without knowing who, where and how to do it. The nested blueprint feature, as an example, I had a prototype running earlier this year already, but got it to an extension / plugin instead of the Sanic core exactly because there is no outlines on how to do it, something I already expressed in an issue an got no response. Sometimes this can be frustrating.

Please, don't get me wrong, I'm not buzzing for these things in the past (that now requires some kind of answer), they are just examples (in my case) for a developer wanting to help :-) And I have a lot of ideas ...

Anyway, I'm very happy to see version 0.8.1 on pypi today! Woohoo! :-D


Cheers,
Richard.

Henrik Sommerland

unread,
Sep 9, 2018, 8:11:02 AM9/9/18
to rkue...@gmail.com, sani...@googlegroups.com
Nesting of blueprints is available, It was added a10d746 but it is not in the documentation.

Awesome that 8.1 is on pypi :D Does that affect the task force? Has channelcat commented on this?





--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/d9e6d55f-615f-4118-848f-4e718b402101%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Henrik "TheGrandmother" Sommerland

Adam Hopkins

unread,
Sep 12, 2018, 9:53:35 AM9/12/18
to Sanic Task Force, Rkuesters, Sanic Dev
I want to let everyone know that while I want to continue being patient, I personally am somewhat frustrated by how this project seems to operate without transparency. I'm not sure if channelcat and team have been having conversations or not on how to proceed.

Assuming they are, I will quiet down. But, in the absence of a response, I wanted to let the group know that I will be proposing how I think we can collectively fork the project under a new community based organization.

If you are interested in this, please let me know. I strongly believe there is a future here, and that it MUST be community based or else it will fail. If we need a new community, then let's build it. But the time for waiting is nearing an end.

--
Adam Hopkins



Sep 9, 2018, 3:10 PM by henrik.s...@gmail.com:

Richard Kuesters

unread,
Sep 12, 2018, 10:00:37 AM9/12/18
to sani...@googlegroups.com
I must admit that the silence so far is indeed frustrating - mostly for not knowing if the talks are advancing or not, just like Adam said. I'm keen to work on the development of Sanic, under this same name or not, because there's a lot of work to be done.

My best regards,
Richard.


To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LMD2jVN--3-1%40amhopkins.com.

Stephen Sadowski

unread,
Sep 12, 2018, 4:23:39 PM9/12/18
to Sanic Task Force
I questioned over a month ago whether or not a fork was necessary given the sheer lack of response from Michael (channelcat) or anyone else that has commit/merge access - and even more than that, I think that Michael is still the only one with pypi access.

In the mean time, we're waiting for a response that might or might not come.

If we could get a response - or even be added to whatever mailing list or group conversation is being had, that would be one thing, but we haven't really been invited so far.

It was almost a week ago when Michael said he was touching base with the designated maintainers and we haven't heard a peep since.

So I guess I'll ask the question again: should we be looking at a strong fork in order to keep Sanic moving forward?

-S

Raphael Deem

unread,
Sep 12, 2018, 4:41:29 PM9/12/18
to stephen....@gmail.com, sani...@googlegroups.com
Hi folks,

I definitely think the project should be forked. Ideally Channelcat can do something like what was done with flask/pallets, so we can preserve the project's stars, but also add some more maintainers and regain pypi rights.

Beyond that, repeating the same message over and over doesn't really help. So, please try to limit the number of +1 type responses on this email group. 

Best,
Raphael/r0fls


--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.

Stephen Sadowski

unread,
Sep 12, 2018, 4:43:13 PM9/12/18
to Raphael Deem, sani...@googlegroups.com
I've just reached out directly to Michael to see if we can get some insight. Hopefully that is forthcoming.

-S

Adam Hopkins

unread,
Sep 12, 2018, 4:47:22 PM9/12/18
to Raphael Deem, stephen....@gmail.com, sani...@googlegroups.com
Raphael,

As someone with probably a deeper knowledge of sanic than the rest of us ... what's your capacity/desire for being able to bang some more on a new fork?

--
Adam Hopkins


12. Sep 2018 23:41 by raphae...@gmail.com:

Adam Hopkins

unread,
Sep 12, 2018, 5:42:34 PM9/12/18
to Sanic Dev
The way I see it there are two options: transfer and fork.

Here are a few highlights of each option.

Option #1 > Transfer ownership
==============================

- Keep the PyPI account, and therefore "pip install sanic" and the sanic brand/name
- The entire history of commits, issues, PRs continues
- Requires channelcat to "sanction" the new project by doing the transfer inside GitHub and PyPI

Option #2 > Fork
================

- Potentially requires a new PyPI package name
- Keeps the commit and PR history, but we would need to carry forward issues by linking back to the sanic project
- Can be done without anyone needing to touch the existing sanic assets
- Potential for renaming or rebranding (I guess it would conincide with the PyPI name)

Personally, I think Option #1 would be best, and that is what I am trying to push for. However, I think we need to seriously entertain Option #2 as well, so I invite you to weigh in on that. I suggest that we create the organization October 1. This gives channelcat plenty of time to transfer the resources if he chooses to.

Now, how should the organization run?

I like the python-attrs approach:
>  If you’d like to join, just get a pull request merged and ask to be added in the very same pull request! ... The simple rule is that everyone is welcome to review/merge pull requests of others but nobody is allowed to merge their own code.

This seems like a positive way to foster a community of contributors.

However, I think one step further than that, there ought to be a core dev team that is tasked with:
- maintaining consistency and performance;
- tagging and responding to issues; and
- steering the direction of the project.

That core team should also make sure that merges are not taking place without proper updates to documentation and release notes.

As you may or may now know, in the last few months there has been a debate about how the Python project should continue without Guido as BDFL. Should there be a committee? Single person?

Personally, I feel that a committee makes more sense. It takes pressure off of a single person for being solely responsible, and we can establish a set of procedures for how they decide on whate features should be included or not.

Which brings me to releases.

I suggest that there be a regular cycle of releases. Perhaps 4 per year would be a good number to start with. This means that features need to be scheduled into a release, and each release would have a set date for when it progresses from one stage to the next (proposal, development, freeze, testing, release candidate, etc).

Where to go from here?

Regardless if we are going to fork or transfer, there needs to be a group of people willing to get thru all of those open issues and PRs and tag them. It seems like a while since any labels have been applied, and there are many unanswered and duplicates. Once we have a strategy in place, I suggest we get X number of developers to commit to busting through Y issues a day over the course of a week. Ideally we would get a couple sets of overlapping eyes on each one. I think this would help to create an agenda of where to go next.

Then, once there is an organization (including contributor guidelines) and core team, we can use that to start planning the next few release cycles and recruiting people to do the work.

What do you say? Can we commit to the October 1 date?

--
Adam Hopkins


12. Sep 2018 23:43 by stephen....@gmail.com:

Ashley Sommer

unread,
Sep 12, 2018, 6:54:21 PM9/12/18
to Sanic Task Force
Hi Adam, Raphael, Stephen, and others,

I joined this group when Adam created it last week, and I've been watching the discussions, but I haven't had time to join in the conversation until now.

I've been Sanic user since Jan 2017 and a Sanic code contributor since March 2017. I am also the developer of several popular Sanic plugins.

I thoroughly agree with everything that is said above. I've seen Sanic mature into a solid, fast, usable framework, but I've also seen it lose popularity over that time.

Whichever option we choose going forward, I'd like to be part of the core team helping Sanic achieve its goals.

I can help on the technical side writing and maintaining the lower-level parts of Sanic, including the uvloop/asyncio HTTP server and transport layer components, which I have a good working understanding of.

I can also help with responding to Github issues and reviewing/commenting on pull-requests (something I do occasionally already).

I'm not good with the non-technical stuff like documentation, releases, direction, etc but as a team in general I'd like to see us create better documentation, user guides, tutorials, etc to help on-board new Sanic users.

I'm happy to be part of the Sanic Committee if that is the leadership method chosen.

- Ash
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

Stephen Sadowski

unread,
Sep 12, 2018, 6:57:59 PM9/12/18
to Sanic Task Force
I think this needs a new thread for the general sake of keeping the lines of discussion clean.

I'd prefer option 1. I think all of us would. Nobody wants to have to fork this project in reality, based on the responses I've seen. Sanic is a good project and we want the project itself to succeed. With that being said, I agree that we must seriously consider option 2 - if for no other reason than we may never get a timely response.

I like all of the other ideas you have outlined, and would endorse them as a first pass at project governance, knowing that they may need to change to fit the needs of the project over time.

As far as an issue commitment from devs - I'm not super keen on setting a hard limit. Mostly, I just want to see people commit to working on the project - so if a person has time to take on an issue, then it is theirs. We all know from a dev standpoint that the biggest issues are sometimes the easiest to solve and the little ones can drag on forever, so setting a hard time commit seems overkill until people get their legs under them.

I'm willing to commit to 10/1 as a spin-up date, and while I probably won't be committing much code, I'm certainly willing to help keep tabs on documentation, triage and respond to issues, and do those other boring administrative things that most people don't enjoy. I don't love it either, but I think it's necessary that someone own the boring stuff so that others can contribute their own strengths.

-S

Raphael Deem

unread,
Sep 12, 2018, 7:09:02 PM9/12/18
to ashley...@gmail.com, sani...@googlegroups.com
Hi everyone,

Thanks for stepping up Ashley. This is exactly what we need.

Side note, I think that we should stop creating issues related to forking the project and releases, and close all of the existing ones. It's not helping that there are many overlapping issues, but really if it's not about the actual code, imo it shouldn't be a github issue. It should probably just be a discussion here instead.

Back to the current discussion, I think we're all on the same page here about Adam's suggested option 1 being the optimal solution. So, I think we're pretty much beating a dead horse discussing it more, and we really just need to wait for channelcat to do that. Unless we're hashing out the details of option 1, in which case that seems appropriate. On that note, in my opinion, the next step after the mentioned parts of option 1 would be getting a few more maintainers that we can add to the project (e.g. Ashley Sommer). We could maybe break the above "rule" and create a github issue to track down some of the other active community members.

Best,
Raphael

To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/38a0de4c-d35b-47ee-848d-91f30ea74ec6%40googlegroups.com.

Stephen Sadowski

unread,
Sep 12, 2018, 9:06:10 PM9/12/18
to Sanic Task Force
I agree that we should no longer worry about issues related to forking/releases. I believe all the existing ones are closed, but I'd have to double-check.

What I'm not exactly sure of is how to reach out to the active committers to get them to commit to assistance on a new project. I am very grateful to have Ashley and Adam, both with their own constituent projects, helping us push forward - but can we do more than Adam has already, by reaching out to people and adding them to this (or a future) group?

I don't want to step on anyone's toes that is currently involved with Sanic. Much of what we're discussing here is out of a need for a more open, responsive, and active project. For a project that has a tagline of 'Gotta go fast' it seems like we're suffering from an inability or lack of desire to do so.

One thing I'd like to propose is that going forward, we commit to at least two supported branches: an LTS branch for stability, and another branch that continues to move forward. I think choices like that help projects like Sanic ensure that when people choose to adopt a technology or framework, they can reasonably expect that if they commit to an 'LTS' branch, they will know what they're getting in return.

Thanks,
-S
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

Adam Hopkins

unread,
Sep 13, 2018, 3:42:42 AM9/13/18
to Sanic Dev
Ash: Thank you so much for your past contributions. I am happy to have your voice in this conversation, and to see you continuing to invest your time here.

Raphael: Same to you. I agree, I would like to see GitHub issues for code, discussions in email mailing list. If you have not seen it, I did post the link to this mailing list here: https://github.com/channelcat/sanic/issues/1245#issuecomment-419077816

Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?

## ORGANIZATION

There seems to be two main organizational components we need: the daily lower level work (development, testing, issues, etc), and the higher level longer term work (planning, enhancement acceptance, releases, etc). These functions roughly equate to what we have been calling the core team and the committee.

For now, I propose that we have a single group of people that function in both capacities. When the project grows much larger, and once we see how things work in a more group/collaborative format, we can revisit the idea.

The people that have stepped up so far include:
- Raphael Deem
- Adam Hopkins
- Richard Kuesters
- Stephen Sadowski
- Ashley Sommer
- Henrik Sommerland

It might be nice if we can grow this list by another 6 to 10 people. Anyone else interested that has not been included?

## TODO

Ash/Raphael: As two of the veteran sanic contributors, can you each provide us with what you see as your "top" most pressing issues to address?

I invite everyone else to do the same. Richard, I know you have a good list of ideas.

So we can keep things organized, I ask that when you respond to this, copy and paste the list from the most recent emails so we do not lose anything:

\\\\\\\\\\\\\\\\\\\\\\\\\\
Top Development Objectives
==========================
-
\\\\\\\\\\\\\\\\\\\\\\\\\\

Stephen: Do you want to take a stab at pulling together a code of conduct and contributor guide? I am happy to work on this with you. We can use what is out there already, and take a look at some other popular python projects: www.attrs.org/en/stable/contributing.html, https://pandas.pydata.org/pandas-docs/stable/contributing.html, https://pylonsproject.org/community-how-to-participate.html, http://docs.celeryproject.org/en/master/contributing.html, http://www.sqlalchemy.org/participate.html.

## DECISIONS

1. The elephant in the room: what if Michael does not provide access to PyPI?

2. Release cycle

My proposal:
The first release from this new organization be a "1.0 LTS", and change classifiers from "Development Status :: 4 - Beta" to "Development Status :: 5 - Production/Stable".

If we commit to a regular cycle, I think switching to CalVer (https://calver.org) makes sense.

18.12 LTS
19.03
19.06
19.09
19.12 LTS

Major features and enhancements are frozen two months before the release (January for 19.03, April for 19.06, etc). This provides ample time for creating stable releases with documentation. And, it is a fairly regular enough schedule that if something misses one release, it does not have to wait too long before being added to the next.

Each release has a designated release manager (it could be the same person each time). The point is, someone takes responsibility for each release to push it along. I think it would be better if it rotated. But, people need to be willing to do it.

At all times we could then have open a branch for the current LTS, and the next two releases. I suggest these be protected branches, and that it is the release managers job to merge into the protected branch after all reviews and status checks are complete.

All PRs require at least two reviews, not including the release manager. His/her job is not necessarily to decide on features and do the review, but more just to keep things moving and pushing others.

3. Features and enhancements

Assuming we have a group of 10-20 volunteers, how do we decide what features to include in a release? Vote of 51%?

4. Repositories

What repositories should the organization control? Should any of the existing features be removed to a separate package (ex. testing)?

It has been suggested that an organization might also adopt some of the more popular third-party packages (https://github.com/channelcat/sanic/issues/1245#issuecomment-415159651).

On a related note, while I am a huge fan of Aymeric's work on the websockets package, I would like to see its requirement pulled out separately as an option: pip install sanic[websockets]. There may be some other features we can pull out as optional.

5. Style Guide

Anyone have an opposition to adopting black (https://github.com/ambv/black) to help enforce style consistency?

6. Standards

There used to be some benchmark standards. I am not sure what happened to them. Anyone want to work on creating a new set? Since one of the features and draws of the framework is its relative speed, I suggest we adopt a benchmark standard that commits need to pass before being adopted.

Same thing for testing. We can do better than the current 83%.

7. Next steps/first release

What would a first community backed release look like? I would suggest that we tackle any low hanging fruit, and not any major changes. The main goals for a first release being increased testing and code coverage, documentation, and stability. Once we have an LTS in place, then we start planning the features for the 19.03 release.

--
Adam Hopkins


13. Sep 2018 04:06 by stephen....@gmail.com:

To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/38a0de4c-d35b-47ee-848d-91f30ea74ec6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.

Michael Hill

unread,
Sep 13, 2018, 5:00:19 AM9/13/18
to Sanic Task Force
Hey all, I am sorry it takes me so long to get back to these issues.  

I recently haven't had much time available so I've started transferring ownership.  I've created a new org called "huge-success" and moved the project there.  I gave ownership over the org to the current maintainers (Raphael and Eli) and Adam so far.  I trust you all to carry Sanic into the future and do right by the maintainers and community.  

I tested a deploy to pypi and it looks like the encrypted credentials work.  I'm not sure if I need to transfer ownership or what that would look like for a github org.

Adam Hopkins

unread,
Sep 13, 2018, 5:10:05 AM9/13/18
to Michael Hill, Sanic Task Force
Michael:

I think we can all appreciate the time crunch, and your efforts. Thank you for your cooperation.

As for PyPI, you can add maintainers here for push access, etc: https://pypi.org/manage/project/sanic/collaboration

--
Adam Hopkins


13. Sep 2018 12:00 by chann...@gmail.com:

Hey all, I am sorry it takes me so long to get back to these issues.  

I recently haven't had much time available so I've started transferring ownership.  I've created a new org called "huge-success" and moved the project there.  I gave ownership over the org to the current maintainers (Raphael and Eli) and Adam so far.  I trust you all to carry Sanic into the future and do right by the maintainers and community.  

I tested a deploy to pypi and it looks like the encrypted credentials work.  I'm not sure if I need to transfer ownership or what that would look like for a github org.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.

Richard Kuesters

unread,
Sep 13, 2018, 9:43:40 AM9/13/18
to ad...@amhopkins.com, chann...@gmail.com, sani...@googlegroups.com
That some very good news! I'm very happy about how things are moving 😊

Michael, thanks a lot for everything so far. Now, to really have an "independent" organization all that's needed is the PyPI access. We can do that by:

1. Having at least another maintainer to PyPI, as Adam mentioned earlier; or
2. Change ownership to a group account (see here for more info).

 In the second case, we can go for a organizational structure, just like Flask did. Then, there's the organization name and everything else pointed out, not in that exclusive order. A list for these "higher-level" tasks will be necessary, I may add.

If any help is needed, you can count on me as well. Oh boy I'm very excited! :-)


My best regards,
Richard.


To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LMHBRWN--3-1%40amhopkins.com.

Stephen Sadowski

unread,
Sep 13, 2018, 10:24:45 AM9/13/18
to Sanic Task Force
I can and will start looking at various codes of conduct and contribution guides, starting with the ones that were linked. If someone gives me appropriate access to the project now that Michael has moved it (Thank you, Michael!) I can start tagging and triaging issues as well.

Andy Xu

unread,
Sep 13, 2018, 5:09:15 PM9/13/18
to Sanic Task Force
+1

I'm very familiar with the codebase and happy to take some maintaining responsibilities, and also involves into technical/design/admin discussions.

Glad we can push this forward. That's great!


To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/38a0de4c-d35b-47ee-848d-91f30ea74ec6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

Adam Hopkins

unread,
Sep 19, 2018, 7:53:03 PM9/19/18
to Sanic Task Force
Hey everyone...

Unless there are more opinions, I want to get everyone that has expressed interest setup on the organization.

Also.... Please take a look at this email again and give us your thoughts on the numbered "decisions" 2-7.

--
Adam Hopkins



Sep 13, 2018, 10:42 AM by ad...@amhopkins.com:
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.


--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.

Adam Hopkins

unread,
Sep 19, 2018, 7:56:37 PM9/19/18
to Sanic Dev
I'm all for keeping and modifying what is there. We can make use of the GitHub templates that prompt users to fill out a "form" when creating a new PR.


--
Adam Hopkins



Sep 14, 2018, 11:17 PM by stephen....@gmail.com:
So I think the code of conduct that is already included is sufficient. It's precise without being overly specific and covers most of what we need.

I think the bigger question is do we want to replace the contribution guide as a whole, or simply extend it? I think there's value in both paths, but it would be less disruptive to extend it than to replace it entirely. I feel like we need to clarify how to submit PRs and what needs to be included. Being very specific about PR naming would help us do things like automate changelog updates, but also requiring that any new additions be submitted with test fixtures and updated documentation would be important as well. Technical bits of contributing that aren't really touched on currently.

Thoughts?

-S

On Fri, Sep 14, 2018 at 11:02 AM Stephen Sadowski <stephen....@gmail.com> wrote:
I'll take a look - submitted a PR for the updated changelog. Man is it a doozy!

On Fri, Sep 14, 2018 at 2:28 AM Adam Hopkins <ad...@amhopkins.com> wrote:

I just heard about this PEP that is all about how Python is reorganizing itself after the departure of Guido. While clearly we are not st the same scale, maybe there are some ideas in here we can adopt.

--
Adam Hopkins



Sep 14, 2018, 12:43 AM by stephen....@gmail.com:
No, I've got it. I'm used to dealing with legal stuff from a professional standpoint, so it's not a big deal. I think the biggest issue will just be finding a model that will allow the greatest freedom of contribution while still being fair and reasonable on conduct side. I've seen some of the issues over the last 18 months where the code of conduct has been used against key contributors to projects, and I honestly don't care about race, nationality, sexuality, or creed of a contributor and don't want any of that to be in play at any point.

-S


On Thu, Sep 13, 2018 at 4:36 PM Adam Hopkins <ad...@amhopkins.com> wrote:
I hear you. I'm in the same boat. I am a little frustrated by the continued silence, but I guess that is what we have to deal with until we are fully accepted that this is the new strategy going forward.

Do you want any help looking through any of that stuff? I am also a lawyer (jokes welcome), so I am used to ready through boring dull stuff.

--
Adam Hopkins


14. Sep 2018 00:08 by stephen....@gmail.com:

Yup, no worries. Not trying to make waves, just trying to help clean up some outstandings!

On Thu, Sep 13, 2018 at 4:03 PM Adam Hopkins <ad...@amhopkins.com> wrote:
Stephen: I am writing to you personally. As an FYI ... I am waiting to hear from some more people on the thoughts I laid out (Committee/Core, etc) before adding any teams to the sanic organization.

--
Adam Hopkins




Richard Kuesters

unread,
Sep 20, 2018, 11:06:18 AM9/20/18
to ad...@amhopkins.com, sani...@googlegroups.com
Ok, here I go with my comments ...

1. The elephant in the room: what if Michael does not provide access to PyPI?

I’m very worried about that, we just got some half-measures so far…

2. Release cycle

I’m one of “these folks” that believe there’s a huge gap between a beta piece of software to a stable piece of software. Beta, for me, means that it works well; have a very strong and healthy community; code coverage is near 100% on almost every platform we can reach and the design of the code is mostly sustainable, with a lot of documentation. As for being production stable, the only difference is having feedback from those who uses it, for how long it uses and what their metrics says about the framework. Yes, I know, this can take a while. But that’s just for the development status, my two cents.

For the rest of the release proposal, I agree to use CalVer because we know there will be a lot of new (and fixed) things and that work might take a while. We can focus, from time to time, to solve most the issues, discuss and review PRs, adjust the documentation accordingly and use this as bases for LTS releases. LTS releases don’t quite requires a fixed release cycle, but mostly observe code quality, issues growth and PRs submitted. One of the main reasons I propose this is the evolution of dependencies and also Python versions; let’s take for example the websockets or multidict: some of their upgrades have broke Sanic here and there.

(item 2) Each release has a designated release manager (it could be the same person each time).

Agreed.

3. Features and enhancements

I guess 50% + 1 is the fairest model (excluding the author, for biasing reasons), and if a minerva vote is required, that shall be given to the author if a PR is also provided under our code of conduct. I just don’t know if these discussion can occur on github (open to everyone) or in the group and what to do if some member is unable to vote for any reason (due date?). I mean “discussion” because we need to provide a constructive feedback instead of “yes” or “no”, not only for us but to encourage others to do the same without the “fear” of being bashed over an idea that might sound stupid for one or other individual (we’re humans after all).

4. Repositories
(item 4) What repositories should the organization control? Should any of the existing features be removed to a separate package (ex. testing)?

I think this might be a good idea, since I’ve seen some users complaining about having aiohttp as a dependency just because of the test client. Perhaps websockets support can be separate as well, so we can mitigate any problems regarding the websockets dependency in a different project without the need to touch Sanic itself at all.

(item 4) It has been suggested that an organization might also adopt some of the more popular third-party packages (https://github.com/channelcat/sanic/issues/1245#issuecomment-415159651).

That might help other developers to have a better visibility of the Sanic ecossystem, although I feel a little dubious about it because these packages will need maintainance the same way as Sanic; why? Just check out how many forks of sanic-openapi are out there. Even I made one in my early days with Sanic ;-D

This also opens a door for optimizations, C, Cython, you name it. We already depend on binary libraries anyway (httptools does not provide a pure Python version AFAIK).

(item 4) I would like to see its requirement pulled out separately as an option: pip install sanic[websockets]

That would be a great idea as well!

5. Style Guide

black, oh yes! Let’s stick to 79 lines (as PEP8 requires) and just use black for consistency. The code remains readable and should pass in any other linters. Of course, there are some ideas and models for other tools like isort, but this debate can be left for another time.

6. Standards
(item 6) There used to be some benchmark standards. I am not sure what happened to them. Anyone want to work on creating a new set? Since one of the features and draws of the framework is its relative speed, I suggest we adopt a benchmark standard that commits need to pass before being adopted.

This is nice, though debatable: a new feature may be awesome, but can slow down Sanic by 3% overall (naive example). How do we handle these trade-offs?

(item 6) Same thing for testing. We can do better than the current 83%.

Hell yeah. At least 95% should be testable.

7. Next steps/first release
(item 7) What would a first community backed release look like? I would suggest that we tackle any low hanging fruit, and not any major changes. The main goals for a first release being increased testing and code coverage, documentation, and stability. Once we have an LTS in place, then we start planning the features for the 19.03 release.

Agreed as well.



My best regards,
Richard / @vltr


--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LMoFtSN--3-1%40amhopkins.com.

Stephen Sadowski

unread,
Sep 20, 2018, 11:35:11 AM9/20/18
to Sanic Task Force
I very much want to just +1 Richard here, but since I was already composing a response, I'll paste my stuff inline


On Thursday, September 20, 2018 at 10:06:18 AM UTC-5, Richard Kuesters wrote:
Ok, here I go with my comments ...

1. The elephant in the room: what if Michael does not provide access to PyPI?

I’m very worried about that, we just got some half-measures so far…

I am less worried about this now than before the transition occurred, but I do want to make sure the organization has ownership over the necessary tools - I brought this up before as part of concern about communication (who actually owns the gitter channels? does anyone know?) but it applies across the board. The org - not a person - should have control of resources that concern the project, be it communication tools, release tools, or anything else. 
2. Release cycle

I’m one of “these folks” that believe there’s a huge gap between a beta piece of software to a stable piece of software. Beta, for me, means that it works well; have a very strong and healthy community; code coverage is near 100% on almost every platform we can reach and the design of the code is mostly sustainable, with a lot of documentation. As for being production stable, the only difference is having feedback from those who uses it, for how long it uses and what their metrics says about the framework. Yes, I know, this can take a while. But that’s just for the development status, my two cents.

For the rest of the release proposal, I agree to use CalVer because we know there will be a lot of new (and fixed) things and that work might take a while. We can focus, from time to time, to solve most the issues, discuss and review PRs, adjust the documentation accordingly and use this as bases for LTS releases. LTS releases don’t quite requires a fixed release cycle, but mostly observe code quality, issues growth and PRs submitted. One of the main reasons I propose this is the evolution of dependencies and also Python versions; let’s take for example the websockets or multidict: some of their upgrades have broke Sanic here and there.

(item 2) Each release has a designated release manager (it could be the same person each time).

Agreed.

I am fine with CalVer. I think we should push with getting our test coverage up in order to get to a "1.0" release, or in the nomenclature we will be adopting, likely an 18.12 LTS release. It gives us a bit over 3 months to focus on getting tests done and addressing any outstanding issues with the current release. While I feel like Sanic is stable, now would be a good time - or say, 10/1 if we're being arbitrary - to declare a feature freeze, branch master to get ready for an LTS release, and start applying whatever changes need to be there. If we are doing CalVer, I would suggest that based on Adam's original position, that a release manager be responsible for the calendar year and then the LTS of that year as well. That reduces the number of decisions to be made over who owns what and why things weren't fixed and yada yada yada. It's additional bureaucratic nonsense that prevents us from goin' fast. And we gotta go fast! 
3. Features and enhancements

I guess 50% + 1 is the fairest model (excluding the author, for biasing reasons), and if a minerva vote is required, that shall be given to the author if a PR is also provided under our code of conduct. I just don’t know if these discussion can occur on github (open to everyone) or in the group and what to do if some member is unable to vote for any reason (due date?). I mean “discussion” because we need to provide a constructive feedback instead of “yes” or “no”, not only for us but to encourage others to do the same without the “fear” of being bashed over an idea that might sound stupid for one or other individual (we’re humans after all).

Yes and no. I think the release manager should not be voting in normal circumstances, but the minerva vote should be given to the release manager, not the author of a PR. The author of a PR will have an inherent bias towards inclusion, the release manager will have a vested interest in seeing a quality release go out the door. It doesn't remove bias towards a feature, but it does reduce it. 
4. Repositories
(item 4) What repositories should the organization control? Should any of the existing features be removed to a separate package (ex. testing)?

I think this might be a good idea, since I’ve seen some users complaining about having aiohttp as a dependency just because of the test client. Perhaps websockets support can be separate as well, so we can mitigate any problems regarding the websockets dependency in a different project without the need to touch Sanic itself at all.

I think the org should handle repos that are no longer supported by the author but deemed important for Sanic's technical success. I don't want to get to the point where 'huge-success' is just an umbrella for all things Sanic as it would muddy the waters.  

(item 4) It has been suggested that an organization might also adopt some of the more popular third-party packages (https://github.com/channelcat/sanic/issues/1245#issuecomment-415159651).

That might help other developers to have a better visibility of the Sanic ecossystem, although I feel a little dubious about it because these packages will need maintainance the same way as Sanic; why? Just check out how many forks of sanic-openapi are out there. Even I made one in my early days with Sanic ;-D

This also opens a door for optimizations, C, Cython, you name it. We already depend on binary libraries anyway (httptools does not provide a pure Python version AFAIK).

(item 4) I would like to see its requirement pulled out separately as an option: pip install sanic[websockets]

That would be a great idea as well!

I agree with this. Provided that the core tenet of Sanic is to provide a fast, asynchronous, API-oriented framework, websockets are external to that idea. Routing for a websocket, where necessary, should be available as an external item. Perhaps, though, this is one thing where we do see it as partially necessary for larger adoption and success of the project, and so it stays under the umbrella (see above) 
5. Style Guide

black, oh yes! Let’s stick to 79 lines (as PEP8 requires) and just use black for consistency. The code remains readable and should pass in any other linters. Of course, there are some ideas and models for other tools like isort, but this debate can be left for another time.

I'm fine with rigorous enforcement of style for a publicly consumable project. Black is fine in my book. 
6. Standards
(item 6) There used to be some benchmark standards. I am not sure what happened to them. Anyone want to work on creating a new set? Since one of the features and draws of the framework is its relative speed, I suggest we adopt a benchmark standard that commits need to pass before being adopted.

This is nice, though debatable: a new feature may be awesome, but can slow down Sanic by 3% overall (naive example). How do we handle these trade-offs?

(item 6) Same thing for testing. We can do better than the current 83%.

Hell yeah. At least 95% should be testable.

Agreed. See above. I think this should be our first target. 
7. Next steps/first release
(item 7) What would a first community backed release look like? I would suggest that we tackle any low hanging fruit, and not any major changes. The main goals for a first release being increased testing and code coverage, documentation, and stability. Once we have an LTS in place, then we start planning the features for the 19.03 release.

Agreed as well.

+1

Stephen Sadowski

Richard Kuesters

unread,
Sep 20, 2018, 12:05:31 PM9/20/18
to abucke...@gmail.com, Stephen Sadowski, sani...@googlegroups.com, ad...@amhopkins.com
Stephen, Alec, all,

Re-reading what I wrote regarding item 3, I think I owe you all an apology because I was not able to correctly put my idea into words. I'll try to break them down:

For voting: I'm thinking way ahead of time, when the time comes to insert new features into Sanic. Of course, not all new features would have to go through this bureaucracy I mentioned if is a simple feature or something that would bring nothing but benefits, but for more sensible things, let's say, a new feature that might break backward compatibility, I think that the "voting" will be almost natural.

For minerva voting: I gave the idea to leave an eventual minerva vote for the author with a PR to be more like an encouraging variable to other developers to bring new features to Sanic - instead of just opening an issue saying "I want support for Jinja templates", and that's it ;-)


My best regards,
Richard.



On Thu, Sep 20, 2018 at 12:43 PM alec buckenheimer <abucke...@gmail.com> wrote:
Hey Folks,

Happy to see sanic start gaining some momentum again, would love to be involved in some way.

2. One thing I would mention when it comes to assigning a "production" label to sanic is that 8.1 was the first release of sanic that would even pip install on windows. Qualitatively it seems like windows is a secondary concern for most sanic development and I'm not necessarily suggesting we make it an officially supported deploy platform but we should at least have a discussion about what guarantees we make there (if any).

3. My guess is most things won't need to come down to a vote and I don't think we should make them if they don't have to. So far it seems the biggest obstacle to getting PR's merged has just been getting them reviewed. That said if something does become contentious totally fine with majority rules

4. I think before another repository gets on boarded it should have a champion / lead, there are definitely some things that make sense as sanic adjacent repos but we have to commit to maintaining them if we onboard responsibilities.

5. strong proponent of pep8, mildly displeased with how ugly black tends to be but if it makes life easier than so be it.

6. I think a benchmark suite would be an awesome idea

7. +1

--
You received this message because you are subscribed to a topic in the Google Groups "Sanic Task Force" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sanic-dev/WXbBxNo7Zek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/b2a6230e-7996-4489-9c68-1fd170dd660f%40googlegroups.com.

Adam Hopkins

unread,
Sep 20, 2018, 6:33:00 PM9/20/18
to Sanic Dev

Great stuff everyone! Let me try and recap and respond.


#############
The Core Devs
#############
- Alec Buckenheimer

- Raphael Deem
- Adam Hopkins
- Richard Kuesters
- Stephen Sadowski
- Ashley Sommer
- Henrik Sommerland
- Eli Uriegas
- Yun Xu


#########################
1. Access to Sanic assets
#########################

I reached out to Michael again. I ask that the other people on this list (Michael being one of them) that have a relationship with him do the same.

The assets are (in relative priority order):
PyPI, ReadTheDocs, Travis, Gitter


##############################################
2. Release Cycle - Switch to CalVer with a LTS
##############################################

Okay ... so maybe I was going to far to upgrade the classifier. I am fine leaving that on Beta, but I would really like to see some major change that would signify the change to the new organization and a commitment to an LTS.

Seeing no dissenting opinions, can we agree to 18.12LTS? There will be a feature freeze. We cleanup the low hanging fruit, and non-controversial PRs that can be added; and up the testing coverage.

+1 to the year long release manager. Stability + responsibility == big win.

I see two strategies here.

(A) The RM runs from December to November, or
(B) January to December.

I think the second would be better with the LTS coming at the end of the year. And then there being some period of time after that (18 months?) that the RM would still be involved in maintaining that LTS.

Option A means we need one RM right now. Option B means we need two ... or one person willing to stick it out for both 18.12 and 19.12.

I suggested 4 releases per year to keep us moving fast.

Alec, Windows support is somewhat "secondary" here not for any conscious decision, but because support for Windows on uvloop has a somewhat treacherous path: https://github.com/MagicStack/uvloop/issues/14. I honestly did not even realize that the current version was running. Glad to hear it is.


###########################
3. Deciding on new features
###########################

I certainly don't want to impede "going fast". On the one hand, we want to give the RM some leeway to make decisions and push the next release. On the other, we want to keep this community driven.

How about this:
- If the PR is "Level 1", then it requires one review (the RM).
- If the PR is "Level 2", then it requires two reviews (RM + 1).
- If the PR is "Level 3", then it requires three reviews (RM + 2).
- If the PR is "Level 4", then it requires 51% of core devs.
    - Vote excludes PR author and RM. If the is a tie, the RM breaks it.

Level 1 - Documentation fixes (typos) and insignificant changes.
Level 2 - Bug fixes and minor changes that have NO impact on API, tests, or speed standards.
Level 3 - Most new features and enhancements would come here. NO impact on tests, or speed standards. Does not break backwards compatibility.
Level 4 - Anything that: breaks backwards compatibility, negative impact to tests or speed standards, adds a new third-party dependency, or is a major shift or feature with a big impact on the API.

In all cases, the author of a PR cannot be a reviewer (which I believe is GitHub enforced).


###########################
4a. Additional repositories
###########################

Well, we have sanic-openapi as well. Anyone want to be a champion there? I gave up on using it because (quite honestly) I could not be bothered to right yet ANOTHER schema for my API.

+1 for the idea that we only absorb the repos that are "critical" to sanic and do not have their own maintainers.


#######################
4b. Breaking things out
#######################

I am putting in a proposal that somewhere in 2019 we pull websockets out into its own `huge-success/sanic-websockets` repo (or at least pip install sanic[websockets]). To the extent that Aymeric is willing to help on this, that would be awesome. As anyone that has flipped through the issues knows, there is some work to be done here.

Same thing for testing. I'd like to see that removed, and put into another package. Say .... pytest-sanic. Yun, I am looking at you on this one.

Also the Dockerfile belongs in its own repo.


##############
5. Style Guide
##############

Any dissenting opinions: we add black to the build requirements as a precommit hook?

Here is what I get when I run it on the current master:

sanic/__init__.py         |   4 +-
sanic/__main__.py         |  51 +--
sanic/app.py              | 669 ++++++++++++++++++++++++-------------
sanic/blueprints.py       | 307 +++++++++++------
sanic/config.py           |  19 +-
sanic/constants.py        |   2 +-
sanic/cookies.py          |  48 +--
sanic/exceptions.py       |  42 +--
sanic/handlers.py         |  78 +++--
sanic/http.py             | 179 +++++-----
sanic/log.py              |  35 +-
sanic/reloader_helpers.py |  34 +-
sanic/request.py          | 173 ++++++----
sanic/response.py         | 284 +++++++++-------
sanic/router.py           | 181 +++++-----
sanic/server.py           | 357 ++++++++++++--------
sanic/static.py           |  76 +++--
sanic/testing.py          |  76 +++--
sanic/views.py            |   7 +-
sanic/websocket.py        |  37 +-
sanic/worker.py           |  87 +++--
21 files changed, 1686 insertions(+), 1060 deletions(-)


################################
6. Standards - Testing and Speed
################################

- No PR can reduce code coverage.
- No PR can significantly reduce benchmarking.

I say significant in the "statistically sginificant" sense of the word, and not that the drop in performance is "large".

Anyone want to take on the creating of a benchmarking script? What happened to the one that used to be out there?


################
7. Version 18.12
################

Sounds like we are all in agreement on freezing, and testing. Anyone stepping up to be the first RM?



--
Adam Hopkins


20. Sep 2018 19:05 by rkue...@gmail.com:

Stephen, Alec, all,

Re-reading what I wrote regarding item 3, I think I owe you all an apology because I was not able to correctly put my idea into words. I'll try to break them down:

For voting: I'm thinking way ahead of time, when the time comes to insert new features into Sanic. Of course, not all new features would have to go through this bureaucracy I mentioned if is a simple feature or something that would bring nothing but benefits, but for more sensible things, let's say, a new feature that might break backward compatibility, I think that the "voting" will be almost natural.

For minerva voting: I gave the idea to leave an eventual minerva vote for the author with a PR to be more like an encouraging variable to other developers to bring new features to Sanic - instead of just opening an issue saying "I want support for Jinja templates", and that's it ;-)


My best regards,
Richard.



On Thu, Sep 20, 2018 at 12:43 PM alec buckenheimer <abucke...@gmail.com> wrote:
Hey Folks,

Happy to see sanic start gaining some momentum again, would love to be involved in some way.

2. One thing I would mention when it comes to assigning a "production" label to sanic is that 8.1 was the first release of sanic that would even pip install on windows. Qualitatively it seems like windows is a secondary concern for most sanic development and I'm not necessarily suggesting we make it an officially supported deploy platform but we should at least have a discussion about what guarantees we make there (if any).

3. My guess is most things won't need to come down to a vote and I don't think we should make them if they don't have to. So far it seems the biggest obstacle to getting PR's merged has just been getting them reviewed. That said if something does become contentious totally fine with majority rules

4. I think before another repository gets on boarded it should have a champion / lead, there are definitely some things that make sense as sanic adjacent repos but we have to commit to maintaining them if we onboard responsibilities.

5. strong proponent of pep8, mildly displeased with how ugly black tends to be but if it makes life easier than so be it.

6. I think a benchmark suite would be an awesome idea

7. +1

--
You received this message because you are subscribed to a topic in the Google Groups "Sanic Task Force" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sanic-dev/WXbBxNo7Zek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.

Richard Kuesters

unread,
Sep 21, 2018, 9:39:12 AM9/21/18
to ad...@amhopkins.com, sani...@googlegroups.com

I’ve read Adam’s recap yesterday and went to bed thinking about some of these stuff.
I think I’ll take the liberty of making a proposal that I believe it can bring more stability to the codebase as well unleash some of the developers to take on what they believe is their strengths:

  • Separate everything related to websockets to a separate project. Not only will this (force us to) solve some of the problems we have in Sanic’s design today but will also give room for Aymeric to provide his more than welcome expertise. I can help with this since I already stumbled on a few hotspots;
  • Also take pytest-sanic under the huge-success umbrella to relieve the Sanic package of having aiohttp as dependency.

This might sound like “extra work” or “not what we initially agreed”, but I think it will be the shortest way to bring the stability we target for Sanic. Furthermore, the timing for doing this is better before the first LTS version than after (to introduce "breaking changes").

That’s just my two cents, more like a personal hint. By no means this should be seen as me trying to “put the wagon in front of the horses” (I don’t even know if this expression exists in English, hahaha), I already accept that the current plan is better for everyone (and way better than no plan at all).


Cheers,
Richard.


To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LMsky0c--3-1%40amhopkins.com.

Stephen Sadowski

unread,
Sep 21, 2018, 10:48:59 AM9/21/18
to Richard Kuesters, ad...@amhopkins.com, sani...@googlegroups.com
My thoughts:

I don't mind if pytest-sanic comes under the umbrella - I consider testing critical to success and if we can include that and reduce dependencies (aiohttp). I was already fine with splitting out websockets, per my earlier responses.

I think at this point I'd like to hear any dissent from the group about Adam's writeup. I'm mostly interested in as-of-yet unvoiced concerns, mostly because I'd like to get them addressed before we start endeavoring to make the changes rather than have them crop up later. I always want us to be willing to hear out the devs, users, and PR authors but I want to kick off the next phase of Sanic with everyone being on relatively the same page.

Thanks,
-S

Richard Kuesters

unread,
Sep 21, 2018, 10:58:49 AM9/21/18
to Stephen Sadowski, ad...@amhopkins.com, sani...@googlegroups.com

I think at this point I’d like to hear any dissent from the group about Adam’s writeup. I’m mostly interested in as-of-yet unvoiced concerns, mostly because I’d like to get them addressed before we start endeavoring to make the changes rather than have them crop up later. I always want us to be willing to hear out the devs, users, and PR authors but I want to kick off the next phase of Sanic with everyone being on relatively the same page.

Me too. C’mon people, we are looking forward for your voice on any matter that comes to mind 😉

Stephen Sadowski

unread,
Sep 21, 2018, 12:21:46 PM9/21/18
to sani...@googlegroups.com
In order for us to fully leverage discourse, I think there's a cost that goes along with it. We could use the open source version, but then we still have the cost of hosting. Rust can absorb that because they have sponsors, with Sanic, we'd need to figure out how to do that.

I would prefer to stick with gitter, as for now there isn't a cost... even if we end up changing the gitter project so that we can roll that under the asset list to be properly managed by the org.

-S

On Fri, Sep 21, 2018 at 10:50 AM alec buckenheimer <abucke...@gmail.com> wrote:
Now that I'm thinking about it we should probably decide on and announce a formal sanic communication channel. The only reference to this forum is via a now closed github issue. I'm fine with google groups being that channel (even though I keep getting mail undelivered errors) but unless there is something we need to discuss that we'd prefer a smaller group for I think it makes sense to memorialize the outcome of the "next steps" discussion in whatever channel we decide on. I'd suggest proposing a simple PR against the README.md with a link to whatever we decide on. Then we can accept the "next steps" proposal unless there are further objections.

personally +1 for discourse, think it works well for the rust community. I know there is a gitter but I'm not sure what the status is on the ownership of that.

--
You received this message because you are subscribed to a topic in the Google Groups "Sanic Task Force" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sanic-dev/WXbBxNo7Zek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CANw3zWmT3EYsBgB-6yvm4wt%2BMW_1ROe__2pboHfAr2W0OZn0jQ%40mail.gmail.com.

Aymeric Augustin

unread,
Sep 22, 2018, 2:45:44 PM9/22/18
to Sanic Task Force
Hello,


Le jeudi 13 septembre 2018 09:42:42 UTC+2, Adam Hopkins a écrit :
Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?

To be honest I'm catching up with the conversation only today. Having a one-month old toddler leaves little time for working on open-source.

I'm confident that things will work out fine — with a caveat for the ideas currently floating around voting; I'll explain below.

Based on my experience with governance of open-source projects, my general advice would be:

- Trust people. Be welcoming. Don't overthink governance. Don't create overlords. Adopt a Code of Conduct and follow common sense rules like "assume good faith", "build consensus around what you're doing", and "don't merge your own patches". Give commit access liberally. Prefer "contributor" to "core dev". (If you're curious why, you can read on dsf-members why we're about to dismantle the Django core team.)

- Ensure all functions are staffed appropriately: writing code is the obvious one, but writing documentation, triaging tickets, managing the release schedule, etc. are instrumental to the success of the project. If there aren't enough volunteers for some of these functions, keep in mind it's an issue and try to onboard new contributors. Make sure the bus factor is kept high especially for GitHub, PyPI, ReadTheDocs, etc. access permissions.

- Consensus beats voting in volunteer teams. Not only do votes create frustration for the losing side, but votes on mailing lists happen under social dynamics that remove many benefits. Not having a secret ballot makes it hard to say no once three respected people have said yes. It's easier to express dissent when it's expected that a discussion will lead to consensus. Voting may be used as a last recourse solution. In that case I would recommend a strong majority, for example 4/5th of cast votes. If there's no consensus, then the status quo wins. If 4/5th feels too conservative, go for 3/5th. This calibrates expectations for the project: everyone knows you need this fraction of the team to agree with you to go ahead. I think that 50% + 1 isn't enough.

Regarding your list of questions, here are very short answers (in the spirit of "strong opinions held weakly"):
1. You'll get it eventually. If you really don't, switch to something like sanic-ng.
2. Use whatever looks nice to you. It won't affect the success of the project. The drawbacks of bikeshedding this decision may outweigh the benefits of a change.
3. Prefer consensus.
4. Once you have an organization that's easy to join, adopting plugin repos makes sense. Trac does this; I transferred a plugin to their org and others are maintaining it now :-)
5. Black is good.
6. I don't know.
7. Yes, clean up the bug tracker and release whatever's ready as soon as you're confident that there aren't too many regressions (or that you can fix them quickly.)

At some point I may have time for open-source again, rewrite websockets to provide a sans-I/O layer, and get in touch to plug that into sanic or sanic-websockets. I'm also keeping an eye on unvicorn which has fairly similar goals and scope.

Best regards,

--
Aymeric.

Adam Hopkins

unread,
Sep 22, 2018, 3:57:13 PM9/22/18
to Sanic Dev, Sanic Dev
I applied to discourse for free hosting for community projects.



--
Adam Hopkins



Sep 21, 2018, 7:21 PM by stephen....@gmail.com:
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.

Stephen Sadowski

unread,
Sep 22, 2018, 4:00:29 PM9/22/18
to Sanic Dev, Adam Hopkins, Sanic Dev
I would be happy to use discourse - I was unaware they had an open source friendly option! I just didn't want us to have to figure out how to pay for it!

Sent from my mobile device; please excuse my brevity

From: sani...@googlegroups.com <sani...@googlegroups.com> on behalf of Adam Hopkins <ad...@amhopkins.com>
Sent: Saturday, September 22, 2018 2:57:11 PM
To: Sanic Dev
Cc: Sanic Dev
Subject: Re: [sanic task force] Re: Pushing Sanic Forward
 

Richard Kuesters

unread,
Sep 22, 2018, 8:21:54 PM9/22/18
to Stephen Sadowski, sani...@googlegroups.com, ad...@amhopkins.com
Yeah! And we do meet their requirements, so let's hope to get a free hosting for discourse and start organizing everything else as well :-)

Aymeric, thanks a lot for your input, it really makes a lot of sense for us to find the guidance we want not only for the project but everything that surrounds it.

As for the good news part, sanicframework.org is ours and we soon hope to have some extra content and make it the entry point for the project, yey! 😎


Cheers,
Richard.



To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/DM2PR0801MB1007AD5AF62C6F987E8F9162AD110%40DM2PR0801MB1007.namprd08.prod.outlook.com.

Adam Hopkins

unread,
Sep 23, 2018, 12:27:35 AM9/23/18
to Aymeric Augustin, Sanic Dev
Wow, this is some great stuff. I'm still internalizing some of your points, but wanted to say thanks for the input.

As a father of 4 soon to be 5, I totally understand the "catch up" time. Regards for your family.

--
Adam Hopkins



Sep 22, 2018, 9:45 PM by aymeric....@polytechnique.org:
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.

Stephen Sadowski

unread,
Sep 24, 2018, 10:54:12 AM9/24/18
to Sanic Task Force
I like Aymeric's insight - as few of us have been actively involved in larger open source projects, hearing about how django is doing it is helpful.

On the other hand, sanic isn't nearly the size nor has the contribution level as django, and I have to wonder if we just embed it in our code that we should periodically - perhaps every LTS release? - review our modus operandi as well as any time a contributor brings a concern to the table about how we are operating.

I can see that if we had tens upon tens of contributors, even hundreds, a core team acting as gatekeepers might slow things down.  I can certainly see how that would prevent those on said 'core team' from contributing in the way they best can.

For now - I'd like to see us pick a direction and go it. In that vein, I'd like to strongly push for the following places to start:

- CalVer 18.12 LTS (beta) with a goal of 19.12 LTS being a stable release, if not sooner. I like the idea of quarterly minimum releases. It'll keep us from the 9 month gap again at minimum.
- I think the release manager should handle releases for a year starting with the LTS, giving that person the responsibility for handling security and other changes to the LTS until the next one is released.
- Consensus decrees for added features or breaking changes to existing features; I will concede the miranda vote to the PR author which I think eliminates me as the sole dissenter for that
- use black as rigorous, opinionated style enforcement
- freeze everything but bug fixes and additional test coverage on 10/1 for 18.12 LTS
- If no one else will volunteer as the RM for 18.12 LTS, I'll do it.

Thanks,
-S


On Saturday, September 22, 2018 at 11:27:35 PM UTC-5, Adam Hopkins wrote:
Wow, this is some great stuff. I'm still internalizing some of your points, but wanted to say thanks for the input.

As a father of 4 soon to be 5, I totally understand the "catch up" time. Regards for your family.

--
Adam Hopkins



Sep 22, 2018, 9:45 PM by aymeric.augustin@polytechnique.org:
Hello,

Le jeudi 13 septembre 2018 09:42:42 UTC+2, Adam Hopkins a écrit :
Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?

To be honest I'm catching up with the conversation only today. Having a one-month old toddler leaves little time for working on open-source.

I'm confident that things will work out fine — with a caveat for the ideas currently floating around voting; I'll explain below.

Based on my experience with governance of open-source projects, my general advice would be:

- Trust people. Be welcoming. Don't overthink governance. Don't create overlords. Adopt a Code of Conduct and follow common sense rules like "assume good faith", "build consensus around what you're doing", and "don't merge your own patches". Give commit access liberally. Prefer "contributor" to "core dev". (If you're curious why, you can read on dsf-members why we're about to dismantle the Django core team.)

- Ensure all functions are staffed appropriately: writing code is the obvious one, but writing documentation, triaging tickets, managing the release schedule, etc. are instrumental to the success of the project. If there aren't enough volunteers for some of these functions, keep in mind it's an issue and try to onboard new contributors. Make sure the bus factor is kept high especially for GitHub, PyPI, ReadTheDocs, etc. access permissions.

- Consensus beats voting in volunteer teams. Not only do votes create frustration for the losing side, but votes on mailing lists happen under social dynamics that remove many benefits. Not having a secret ballot makes it hard to say no once three respected people have said yes. It's easier to express dissent when it's expected that a discussion will lead to consensus. Voting may be used as a last recourse solution. In that case I would recommend a strong majority, for example 4/5th of cast votes. If there's no consensus, then the status quo wins. If 4/5th feels too conservative, go for 3/5th. This calibrates expectations for the project: everyone knows you need this fraction of the team to agree with you to go ahead. I think that 50% + 1 isn't enough.

Regarding your list of questions, here are very short answers (in the spirit of "strong opinions held weakly"):
1. You'll get it eventually. If you really don't, switch to something like sanic-ng.
2. Use whatever looks nice to you. It won't affect the success of the project. The drawbacks of bikeshedding this decision may outweigh the benefits of a change.
3. Prefer consensus.
4. Once you have an organization that's easy to join, adopting plugin repos makes sense. Trac does this; I transferred a plugin to their org and others are maintaining it now :-)
5. Black is good.
6. I don't know.
7. Yes, clean up the bug tracker and release whatever's ready as soon as you're confident that there aren't too many regressions (or that you can fix them quickly.)

At some point I may have time for open-source again, rewrite websockets to provide a sans-I/O layer, and get in touch to plug that into sanic or sanic-websockets. I'm also keeping an eye on unvicorn which has fairly similar goals and scope.

Best regards,

--
Aymeric.



--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

Adam Hopkins

unread,
Sep 24, 2018, 3:07:03 PM9/24/18
to Sanic Dev, Sanic Task Force
Stephen:

Thanks for stepping up! You make some good points, and while we are still a young project a commitment to regularly review practices to avoid the monkey/banana/ladder syndrome.

https://i.snag.gy/kdu77.jpg

=====

Moving on ... the self-imposed October 1 deadline is coming up. Anyone else we have not heard from have some more insight/input on these topics?

Also ... I have been in contact trying to get us some resources. I also think that we should probably have SOME kind of a frontend website if not for posting notices, etc.

I am working on something right now just as an announcement of the move to a community organization. If anyone else would like to help this effort let me know. My thought for now is just a static page generator hosted on GitHub pages with our new domain pointing to it.

--
Adam Hopkins



Sep 24, 2018, 5:54 PM by stephen....@gmail.com:
I like Aymeric's insight - as few of us have been actively involved in larger open source projects, hearing about how django is doing it is helpful.

On the other hand, sanic isn't nearly the size nor has the contribution level as django, and I have to wonder if we just embed it in our code that we should periodically - perhaps every LTS release? - review our modus operandi as well as any time a contributor brings a concern to the table about how we are operating.

I can see that if we had tens upon tens of contributors, even hundreds, a core team acting as gatekeepers might slow things down.  I can certainly see how that would prevent those on said 'core team' from contributing in the way they best can.

For now - I'd like to see us pick a direction and go it. In that vein, I'd like to strongly push for the following places to start:

- CalVer 18.12 LTS (beta) with a goal of 19.12 LTS being a stable release, if not sooner. I like the idea of quarterly minimum releases. It'll keep us from the 9 month gap again at minimum.
- I think the release manager should handle releases for a year starting with the LTS, giving that person the responsibility for handling security and other changes to the LTS until the next one is released.
- Consensus decrees for added features or breaking changes to existing features; I will concede the miranda vote to the PR author which I think eliminates me as the sole dissenter for that
- use black as rigorous, opinionated style enforcement
- freeze everything but bug fixes and additional test coverage on 10/1 for 18.12 LTS
- If no one else will volunteer as the RM for 18.12 LTS, I'll do it.

Thanks,
-S

On Saturday, September 22, 2018 at 11:27:35 PM UTC-5, Adam Hopkins wrote:
Wow, this is some great stuff. I'm still internalizing some of your points, but wanted to say thanks for the input.

As a father of 4 soon to be 5, I totally understand the "catch up" time. Regards for your family.

--
Adam Hopkins



Sep 22, 2018, 9:45 PM by aymeric....@polytechnique.org:
Hello,

Le jeudi 13 septembre 2018 09:42:42 UTC+2, Adam Hopkins a écrit :
Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?

To be honest I'm catching up with the conversation only today. Having a one-month old toddler leaves little time for working on open-source.

I'm confident that things will work out fine — with a caveat for the ideas currently floating around voting; I'll explain below.

Based on my experience with governance of open-source projects, my general advice would be:

- Trust people. Be welcoming. Don't overthink governance. Don't create overlords. Adopt a Code of Conduct and follow common sense rules like "assume good faith", "build consensus around what you're doing", and "don't merge your own patches". Give commit access liberally. Prefer "contributor" to "core dev". (If you're curious why, you can read on dsf-members why we're about to dismantle the Django core team.)

- Ensure all functions are staffed appropriately: writing code is the obvious one, but writing documentation, triaging tickets, managing the release schedule, etc. are instrumental to the success of the project. If there aren't enough volunteers for some of these functions, keep in mind it's an issue and try to onboard new contributors. Make sure the bus factor is kept high especially for GitHub, PyPI, ReadTheDocs, etc. access permissions.

- Consensus beats voting in volunteer teams. Not only do votes create frustration for the losing side, but votes on mailing lists happen under social dynamics that remove many benefits. Not having a secret ballot makes it hard to say no once three respected people have said yes. It's easier to express dissent when it's expected that a discussion will lead to consensus. Voting may be used as a last recourse solution. In that case I would recommend a strong majority, for example 4/5th of cast votes. If there's no consensus, then the status quo wins. If 4/5th feels too conservative, go for 3/5th. This calibrates expectations for the project: everyone knows you need this fraction of the team to agree with you to go ahead. I think that 50% + 1 isn't enough.

Regarding your list of questions, here are very short answers (in the spirit of "strong opinions held weakly"):
1. You'll get it eventually. If you really don't, switch to something like sanic-ng.
2. Use whatever looks nice to you. It won't affect the success of the project. The drawbacks of bikeshedding this decision may outweigh the benefits of a change.
3. Prefer consensus.
4. Once you have an organization that's easy to join, adopting plugin repos makes sense. Trac does this; I transferred a plugin to their org and others are maintaining it now :-)
5. Black is good.
6. I don't know.
7. Yes, clean up the bug tracker and release whatever's ready as soon as you're confident that there aren't too many regressions (or that you can fix them quickly.)

At some point I may have time for open-source again, rewrite websockets to provide a sans-I/O layer, and get in touch to plug that into sanic or sanic-websockets. I'm also keeping an eye on unvicorn which has fairly similar goals and scope.

Best regards,

--
Aymeric.



--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.

Andy Xu

unread,
Sep 24, 2018, 6:19:42 PM9/24/18
to Sanic Task Force
Hey, you guys all make great points.

1. As for test packages, i'm not too worry about that, since test_packages are not direct dependencies. After we deprecating Sanic builtin test_client (https://github.com/huge-success/sanic/blob/master/sanic/testing.py#L18), then looks much clean.
2. Do we have minimum approves for PRs ? i'm fine with 1 or 2.
3. As for Release Manager, maybe we should have 2 Release Managers for first year ?

Thanks,
Yun
Sep 22, 2018, 9:45 PM by aymeric.augustin@polytechnique.org:
Hello,

Le jeudi 13 septembre 2018 09:42:42 UTC+2, Adam Hopkins a écrit :
Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?

To be honest I'm catching up with the conversation only today. Having a one-month old toddler leaves little time for working on open-source.

I'm confident that things will work out fine — with a caveat for the ideas currently floating around voting; I'll explain below.

Based on my experience with governance of open-source projects, my general advice would be:

- Trust people. Be welcoming. Don't overthink governance. Don't create overlords. Adopt a Code of Conduct and follow common sense rules like "assume good faith", "build consensus around what you're doing", and "don't merge your own patches". Give commit access liberally. Prefer "contributor" to "core dev". (If you're curious why, you can read on dsf-members why we're about to dismantle the Django core team.)

- Ensure all functions are staffed appropriately: writing code is the obvious one, but writing documentation, triaging tickets, managing the release schedule, etc. are instrumental to the success of the project. If there aren't enough volunteers for some of these functions, keep in mind it's an issue and try to onboard new contributors. Make sure the bus factor is kept high especially for GitHub, PyPI, ReadTheDocs, etc. access permissions.

- Consensus beats voting in volunteer teams. Not only do votes create frustration for the losing side, but votes on mailing lists happen under social dynamics that remove many benefits. Not having a secret ballot makes it hard to say no once three respected people have said yes. It's easier to express dissent when it's expected that a discussion will lead to consensus. Voting may be used as a last recourse solution. In that case I would recommend a strong majority, for example 4/5th of cast votes. If there's no consensus, then the status quo wins. If 4/5th feels too conservative, go for 3/5th. This calibrates expectations for the project: everyone knows you need this fraction of the team to agree with you to go ahead. I think that 50% + 1 isn't enough.

Regarding your list of questions, here are very short answers (in the spirit of "strong opinions held weakly"):
1. You'll get it eventually. If you really don't, switch to something like sanic-ng.
2. Use whatever looks nice to you. It won't affect the success of the project. The drawbacks of bikeshedding this decision may outweigh the benefits of a change.
3. Prefer consensus.
4. Once you have an organization that's easy to join, adopting plugin repos makes sense. Trac does this; I transferred a plugin to their org and others are maintaining it now :-)
5. Black is good.
6. I don't know.
7. Yes, clean up the bug tracker and release whatever's ready as soon as you're confident that there aren't too many regressions (or that you can fix them quickly.)

At some point I may have time for open-source again, rewrite websockets to provide a sans-I/O layer, and get in touch to plug that into sanic or sanic-websockets. I'm also keeping an eye on unvicorn which has fairly similar goals and scope.

Best regards,

--
Aymeric.



--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.

Richard Kuesters

unread,
Sep 25, 2018, 9:37:35 AM9/25/18
to Andy Xu, sani...@googlegroups.com
I was thinking yesterday about this and I agree with Andy that 2 Release Managers would be better in this "new beginning", mostly if one of them is new (as within the Sanic project) ;-)

Sep 22, 2018, 9:45 PM by aymeric....@polytechnique.org:
Hello,

Le jeudi 13 septembre 2018 09:42:42 UTC+2, Adam Hopkins a écrit :
Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?

To be honest I'm catching up with the conversation only today. Having a one-month old toddler leaves little time for working on open-source.

I'm confident that things will work out fine — with a caveat for the ideas currently floating around voting; I'll explain below.

Based on my experience with governance of open-source projects, my general advice would be:

- Trust people. Be welcoming. Don't overthink governance. Don't create overlords. Adopt a Code of Conduct and follow common sense rules like "assume good faith", "build consensus around what you're doing", and "don't merge your own patches". Give commit access liberally. Prefer "contributor" to "core dev". (If you're curious why, you can read on dsf-members why we're about to dismantle the Django core team.)

- Ensure all functions are staffed appropriately: writing code is the obvious one, but writing documentation, triaging tickets, managing the release schedule, etc. are instrumental to the success of the project. If there aren't enough volunteers for some of these functions, keep in mind it's an issue and try to onboard new contributors. Make sure the bus factor is kept high especially for GitHub, PyPI, ReadTheDocs, etc. access permissions.

- Consensus beats voting in volunteer teams. Not only do votes create frustration for the losing side, but votes on mailing lists happen under social dynamics that remove many benefits. Not having a secret ballot makes it hard to say no once three respected people have said yes. It's easier to express dissent when it's expected that a discussion will lead to consensus. Voting may be used as a last recourse solution. In that case I would recommend a strong majority, for example 4/5th of cast votes. If there's no consensus, then the status quo wins. If 4/5th feels too conservative, go for 3/5th. This calibrates expectations for the project: everyone knows you need this fraction of the team to agree with you to go ahead. I think that 50% + 1 isn't enough.

Regarding your list of questions, here are very short answers (in the spirit of "strong opinions held weakly"):
1. You'll get it eventually. If you really don't, switch to something like sanic-ng.
2. Use whatever looks nice to you. It won't affect the success of the project. The drawbacks of bikeshedding this decision may outweigh the benefits of a change.
3. Prefer consensus.
4. Once you have an organization that's easy to join, adopting plugin repos makes sense. Trac does this; I transferred a plugin to their org and others are maintaining it now :-)
5. Black is good.
6. I don't know.
7. Yes, clean up the bug tracker and release whatever's ready as soon as you're confident that there aren't too many regressions (or that you can fix them quickly.)

At some point I may have time for open-source again, rewrite websockets to provide a sans-I/O layer, and get in touch to plug that into sanic or sanic-websockets. I'm also keeping an eye on unvicorn which has fairly similar goals and scope.

Best regards,

--
Aymeric.



--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/6c565be8-adb0-48a4-a21f-3e52660b3071%40googlegroups.com.

Stephen Sadowski

unread,
Sep 25, 2018, 10:26:47 AM9/25/18
to Richard Kuesters, yunx...@gmail.com, Sanic Dev
I'm fine with two release managers. Or I'm fine with someone else with longer association with the project doing it. I just wanted to make sure there was someone stepping in to the role.

-S


To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CANw3zWk65P6PJWvA4njE2s2Dm6H_XJVvPc5wh%2BB6JNOhE_8fhw%40mail.gmail.com.

Stephen Sadowski

unread,
Sep 25, 2018, 11:32:00 AM9/25/18
to Richard Kuesters, Sanic Dev, Adam Hopkins
Richard,

I thought I saw this - and I did - can we point sanicframework.org at readthedocs for now? And who holds the creds for managing the domain? Is that you?

Just trying to keep track of the assets!

-S

Adam Hopkins

unread,
Sep 25, 2018, 12:02:57 PM9/25/18
to Stephen Sadowski, Sanic Dev, Richard Kuesters, Sanic Dev
Yes, Richard has the domain name. In other news, I made some progress with the PyPI team to hopefully get access to push there. Also, the discourse team is reviewing our eligibility, and I have reached out to the Digital Ocean sponsorship team. I will update when I hear more.

--
Adam Hopkins



Sep 25, 2018, 6:31 PM by stephen....@gmail.com:

Richard Kuesters

unread,
Sep 25, 2018, 12:11:31 PM9/25/18
to ad...@amhopkins.com, Stephen Sadowski, sani...@googlegroups.com
Stephen, yes, I registered the domain for us. We are looking into discourse and Digital Ocean as Adam mentioned and I think he's working on an idea of a static page for the domain but, of course, I think "docs.sanicframework.org" could point to RTD.

I mean, we are all working on something for Sanic and when all variables become available, we'll see what's best for each situation :-)

Adam Hopkins

unread,
Sep 25, 2018, 7:22:33 PM9/25/18
to Richard Kuesters, Sanic Dev
My suggestion:

forums.sanicframework.org - Discourse
sanicframework.org - GitHub Pages

No update on discourse. But I put together a draft announcement. Unless anyone has any strong opinions, I am thinking of using Pelican with the Brutalist theme, and building static pages to GH.



--
Adam Hopkins



Sep 25, 2018, 7:11 PM by rkue...@gmail.com:
Stephen, yes, I registered the domain for us. We are looking into discourse and Digital Ocean as Adam mentioned and I think he's working on an idea of a static page for the domain but, of course, I think "docs.sanicframework.org" could point to RTD.

I mean, we are all working on something for Sanic and when all variables become available, we'll see what's best for each situation :-)

Stephen Sadowski

unread,
Sep 25, 2018, 8:03:07 PM9/25/18
to Adam Hopkins, Richard Kuesters, Sanic Dev
Could we add a small contributing and involvement section towards the end to get people involved in the mailing list, pointing them at the contributing doc in the main repo, etc? I think it would help to make sure people know we want them involved and give them the info that they need.

To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LNI1cvw--3-1%40amhopkins.com.
Reply all
Reply to author
Forward
0 new messages