In article <19336614-0e4f-42bf-a918-1807bb7f3...@stufft.io>, Donald Stufft <don...@stufft.io> wrote: [...] > Well you can’t document your way out of a bad UX. The thing you’re > competing with (on Github at least) is: > > 1. I notice a docs change I can make > 2. I click the “Edit” button and it automatically creates a fork, > and opens up a web based editor where I can make changes to > that file. > 3. I fill out the commit message and hit Save. > 4. An automatic pull request is opened up with my changes. > > I can submit a fix for a typo in the docs in like ~30 seconds assuming > I already have a Github account. That sort of instant win is a great > way to get people started contributing to a project and can lead later > to bigger more substantial contributions. [...] > Mostly what I’m trying to say is that documenting a field that essentially > requires > the end user to not only figure out how to use mercurial, but figure out how > to > host a public repository somewhere is not even really within the same order > of > magnitude in ease of use.
Sure, I get that. But we're not even talking here about the main Python docs since they are part of the CPython repos, only ancillary repos like PEPs and the developer's guide. The level of activity on those is quite small. So, thinking about it a bit more, PEPs don't normally have bug tracker issues associated with them so I suppose my concerns about issue tracker aren't a major concern for them. The dev guide does get issues opened about it and I suppose they could be managed. But, without tackling the CPython repo workflow (a *much* bigger deal), is the divergence in workflows worth it? I dunno. -- Ned Deily, n...@acm.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
