-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Responsibilities of PyCon APAC community #4
base: master
Are you sure you want to change the base?
Conversation
2 points in my PR here: 1. Let's be clear on the responsibilities that the PyCon APAC _committee_ will hold, which gives it the _right_ to endorse certain parties to hold the conference 1. Although I get what this is trying to do, as we're not a registered legal entity ourselves, I do not think it is appropriate to set as a requirement that the organizers are also registered entities. This also needlessly raises the bar for new comers: Nearly of us started our PyCon adventure as individuals getting together and that didn't make the conference less good as compared to with a legal entity.
@@ -23,6 +23,8 @@ help run PyCon Asia Pacific in 2017 in a location they are local to. PyCon APAC | |||
Asia-Pacific countries to come together to meet with fellow Python users. The | |||
same can be said for anyone adopting an exploratory perspective towards Python. | |||
|
|||
The above text proposes that a certain group 'owns' PyCon APAC. The below text also puts forth certain rules and requirements which would-be organizers needs to adhere to before they can be _considered_ as eligable to organize PyCon APAC. If we endorse a certain party, I think we also need to be clear on the responsibility that we hold as the party that endorses a certain organizer. We cannot just say "yes, you can hold PyCon APAC" but do not follow through on issues that might occur after that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better break this to multiple lines. It'll make commenting easier.
This paragraph doesn't look like part of the document, but your comment for the document, @iq8al ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, those are my comments, which should be overwritten with the real text if we can come to a conclusion @yungyuc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to put comments and discussions in github issue/PR tracker. In this way the document itself remains self-contained.
If we really want to put our comments into the document, we should explicitly mark it. Because I don't like this idea, I am not proposing a format. But I think such a format should include a clear todo mark (XXX, FIXME, etc.) and a the commenter's identity.
@iq8al could you go with either way (or another option you like) in your next update of this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, the issue tracker is there to be used anyway, so comments will go there instead. Proposal to editing the document can go as PR then.
2 points in my PR here: