Skip to content

Update governance guidelines #105

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.

Sign up for GitHub

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

Merged
Xymph merged 6 commits into from
Jul 4, 2021
Merged

Update governance guidelines #105

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
fe92a52
Add missing content to CHANGELOG.md
Xymph Jul 2, 2021
9198ba0
GOVERNANCE: Add a provision to unblock PRs
waldyrious Jul 4, 2021
1a9ae64
Adjust process for handling untagged changes in CHANGELOG
waldyrious Jul 4, 2021
e6735a2
Add dates for released versions in CHANGELOG.md
waldyrious Jul 4, 2021
e753041
Format filenames in GOVERNANCE.md
waldyrious Jul 4, 2021
2e771cd
Update changelog entry for governance guidelines
waldyrious Jul 4, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 15 additions & 9 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,12 @@

Since v0.10.0 this project adheres to [Semantic Versioning](http://semver.org/) and [Keep a Changelog](http://keepachangelog.com/).

### Unreleased version
### Upcoming version

#### Added

* Added more debug logging of MediaWiki requests and responses ([#101])
* New GOVERNANCE.md file to explicitly codify the project management principles and provide guidelines for maintenance tasks ([#83])
* New GOVERNANCE.md file to explicitly codify the project management principles and provide guidelines for maintenance tasks ([#83], [#105])

#### Changed

Expand All @@ -17,14 +17,14 @@ Since v0.10.0 this project adheres to [Semantic Versioning](http://semver.org/)

* Prevented PHP notice in `WikiFile::getInfo()` for moved or deleted file ([#85])

### Version 0.12.0
### Version 0.12.0 - 2017-02-03

#### Added

* New class WikiFile to retrieve properties of a file, and download and upload its contents. All properties pertain to the current revision of the file, or a specific older revision. ([#69], [#71], [#78], [#80])
* WikiFile also provides the file history and the ability to delete a file or an older revision of it ([#76])

### Version 0.11.0
### Version 0.11.0 - 2016-11-16

#### Added

Expand All @@ -48,28 +48,32 @@ Since v0.10.0 this project adheres to [Semantic Versioning](http://semver.org/)
* Fixed passing the return value in `WikiPage::setSection()` ([#30])
* Corrected call to `Wikimate::debugRequestsConfig()` ([#30])

### Version 0.10.0
### Version 0.10.0 - 2014-06-24

#### Changed

* Switched to using the *Requests* library instead of Curl ([#25])

### Version 0.5
### Version 0.9 - 2014-06-13

* Bumped version for stable release

### Version 0.5 - 2011-09-09

* Removed the use of constants in favour of constructor arguments
* Added checks that throw an exception if can't write to wikimate_cookie.txt
* Throws exception if curl library not loaded
* Throws exception if can't login

### Version 0.4
### Version 0.4 - 2011-01-15

* Added `WikiPage::newSection()` and `WikiPage::setSection()` (shortcuts to `WikiPage::setText()`)
* Added the ability to get individual sections of the article with `WikiPage::getSection()`
* Added the ability to get all sections in an array with `WikiPage::getAllSections()`
* Added the ability to get array showing section offsets and lengths in the page wikicode with `WikiPage::getSectionOffsets()`
* Added the ability to see how many sections are on a page with `WikiPage::getNumSections()`

### Version 0.3
### Version 0.3 - 2010-12-26

* Initial commit

Expand Down Expand Up @@ -100,4 +104,6 @@ Since v0.10.0 this project adheres to [Semantic Versioning](http://semver.org/)
[#80]: https://github.com/hamstar/Wikimate/pull/80
[#83]: https://github.com/hamstar/Wikimate/pull/83
[#85]: https://github.com/hamstar/Wikimate/pull/85

[#100]: https://github.com/hamstar/Wikimate/pull/100
[#101]: https://github.com/hamstar/Wikimate/pull/101
[#105]: https://github.com/hamstar/Wikimate/pull/105
15 changes: 9 additions & 6 deletions GOVERNANCE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,14 +15,16 @@ if they would like to help maintaining the repository.
(except for very minor ones such as spelling fixes).
2. **Maintainers should not merge their own pull requests**.
This allows every change to be validated by at least another maintainer.
That said, if there's no input by other maintainers in over a week,
the maintainer who authored the pull request can merge their own PR.
3. Pull requests should comprise a single feature or bugfix.
**Unrelated changes should be sent as separate PRs.**
The exception are minor code cleanup changes,
which can be included (as a separate commit) in the PR that prompted them.
4. **Commits should be atomic**
(as small as possible while still representing a self-consistent set of changes)
and have descriptive commit messages.
5. **Every PR should include a CHANGELOG.md entry**.
5. **Every PR should include a `CHANGELOG.md` entry**.
This makes it much easier to prepare releases,
and allows the change author to properly summarize it.

Expand All @@ -32,13 +34,14 @@ A PR should be created with all relevant changes to update the repository for th
(See [#81](https://github.com/hamstar/Wikimate/pull/81) for an example.)
It should apply the following actions:

1. Change the "Unreleased version" heading in the CHANGELOG.md file
to the appropriate version name (e.g. "Version 1.2.3")
and add a new "Unreleased version" section heading above it;
1. Change the "Upcoming version" heading in the `CHANGELOG.md` file
to the appropriate version name and date (e.g. "Version 1.2.3 - 2020-12-31")
Copy link
Copy Markdown
Collaborator Author

@waldyrious waldyrious Jul 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it would make sense to replicate the changes from e2c026c in this PR, so that they're introduced in lockstep with these guideline changes. WDYT @Xymph?

Copy link
Copy Markdown
Collaborator

@Xymph Xymph Jul 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really biased either way, but if you are splitting off commits from #102 anyway, I'm fine with that commit going into this PR too. Along with the initial header change per my comment above.

Copy link
Copy Markdown
Collaborator Author

@waldyrious waldyrious Jul 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't cleanly cherry-pick that commit into this branch, because it includes adding the section header for the new release (which should remain in #102), but I'll recreate the parts that need to be moved and will mark you as co-author of the commit :)

Copy link
Copy Markdown
Collaborator

@Xymph Xymph Jul 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine, if I need to make changes to my branch locally, and pull/push stuff around, please detail any steps.

Copy link
Copy Markdown
Collaborator Author

@waldyrious waldyrious Jul 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, no worries. In fact, I should be able to update your branch myself. Then, if it looks good to you on GitHub, you will be able to pull the updated branch to your local clone as well.

and add a new "Upcoming version" section heading above it,
with the contents "No changes yet.";
Comment thread
waldyrious marked this conversation as resolved.
2. Edit the README and replace all references
to the previous version number and release date
with the corresponding data for the new version;
3. Update all version references in Wikimate.php
3. Update all version references in `Wikimate.php`
to the new version.

Once this PR is merged, a new release should be created
Expand All @@ -49,4 +52,4 @@ The version tag and the title of the release notes should be in the format v1.2.
(following [SemVer](http://semver.org/) conventions
to determine which part of the version number to increase).
The body of the release notes should be a summary of the contents
of the relevant section in CHANGELOG.md.
of the relevant section in `CHANGELOG.md`.