OK, so we need to set that expectation in a contributing.md
document for the repo. We cannot assume that contributors know
our process when it's not documented for a given repo.
GitHub uses contributing.md:
https://help.github.com/articles/setting-guidelines-for-repository-contributors/
Example from another Pylons Project:
https://github.com/Pylons/pyramid/blob/master/contributing.md
I've logged an issue for trypyramid.com:
https://github.com/Pylons/tpc/issues/35
--steve
On 1/2/16 at 1:33 PM, bla...@laflamme.org (Blaise Laflamme) pronounced:
Contributor should be able to compile and see their own changes
before they submit PRs, and we should do the same when
reviewing. The dev branch I was proposing earlier was to help
us merging PR and make sure we don't publish unfinished work on master.
On Saturday, January 2, 2016 at 4:28:29 PM UTC-5, Steve Piercy wrote:
On 1/2/16 at 3:11 PM, mmer...@gmail.com <javascript:> (Michael
Merickel) pronounced:
Hey everyone, I'm starting the discussion (which I hope is
very quick) about what to do with our public websites.
Right now we have:
- docs.pylonsproject.org (docs, hosted on rtd) -
docs.pylonsproject.org/projects (hosted on rtd) -
www.pylonsproject.org (ppo, hosted somewhere controlled by
blaise/ben) - trypyramid.com (tpc, hosted somewhere I have no
idea) - webob.org (hosted somewhere I have no idea) -
docs.webob.org (hosted on rtd)
I think Blaise is the only person with access to DNS configurations but
I'm
not really sure.
I'd like to propose moving several sites over to github pages
for easier management and update the DNS records with CNAME
records to the github pages sites. All of the sites are
static and it would allow master to be always live, as well
as control deployment permissions via the standard
github.com/Pylons membership levels.
The sites I'd like to see updated are:
- www.pylonsproject.org - trypyramid.com - webob.org
Can anyone give me a reason to not go this route?
+1, but with a concern for the non-doc/HTML-only/marketing
sites. How do we preview proposed changes with as much ease
as deploying to a production environment?
Taking trypyramid.com as an example, I could set up a CNAME of
trypyramid.stevepiercy.com, and point it at a particular
branch of stevepiercy/tpc before submitting a PR to
Pylons/tpc. But this would raise a bar for new individual contributions.
Perhaps we declare a branch 'dev' or 'staging' for reviewing
proposed changes, and set up a CNAME for each marketing website?
--steve
------------------------ Steve Piercy, Soquel, CA
------------------------
Steve Piercy, Soquel, CA
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.
